Secrets to Successful Automated Testing with Watir

Automating tests is an investment that is valuable as long as the investment is not too great. As such investing in automated testing tools can be great or bad depending on if your company really needs to automate. We want to get to the payback more quickly. The true investment is not only the cost of creating and maintaining automated tests. Watir is a family of libraries for testing web applications. Watir reduces the cost of creating automated tests that are maintainable. If we spend too much time fixing and debugging, we will never get the new features created, or we will abandon the automated tests temporarily.

Author: Dave McNulla, http://dmcnulla.wordpress.com/

By monitoring Watir-related automation forums (such as Stack Overflow), reading articles, and talking to other test automation principles on the Watir Podcast, I get to learn about the common problems that people have in automating tests using Watir. Some I saw in my own test automation adventures. We can avoid most of the problems that are violations to key principles of test automation.

Use the Best Tool for the Job

The funniest thing to see is somebody trying to hammer a nail with a screwdriver – funny because it happens rarely. If somebody is using the wrong tool, it’s because they do not have access to the right tool, or they are not aware the other tool exists. People run into problems when they try using Watir for something it’s not designed to do. Watir doesn’t do everything. Watir stands for Web-Application-Testing-In-Ruby. It’s a successful library because Ruby. Ruby is successful because there are so many libraries that integrate with it. Learn about these libraries, get comfortable with them to find your time being spent more effectively.

The tools I use include database clients, file utilities, and rest clients. Sometimes I use active-record with Ruby-on-Rails applications. For restful web services clients, I typically create my own classes using net/http or net/https.

My favorite place to find Ruby tools is https://www.ruby-toolbox.com.

Test One Thing at a Time

Successful automated tests are short declarative statements, not epic stores. When I have a test that creates a user, then logs that user in, then change user settings, I am testing useful things. Each of those capabilities needs to work. If the administrator feature of creating a user fails, stops working, then the test will not discover is the user log-in works, or if changing user settings works.

Use the application-under-test as little as possible to create the conditions for the current test. One test should verify creating a user, while another verifies a created user can log in. How can you log in a user that hasn’t been created yet? Create the user through direct database manipulation and mocks. Here is the opportunity to use those other Ruby tools.

Watir script example. Source: Watir Tutorial

Create Behavior Building Blocks

Your automated tests mix what with how? Suppose you wanted to test changing the user’s preferences. You would answer yes if you have a test script that has a line similar to the following:
browser.button(id: “submit”)

A better example would be to describe the what the user is doing, not how. They are submitting a form, their vehicle for doing that is clicking the button. When the method to submit changes, all the tests that use that how will cease to work. Behavior-driven tests would say something like:
preferences.submit()

The submit method allows you to encapsulate how the form is submitted. When I initially started encapsulating the how, I used the first option with functional programming. I learned the better way of object-oriented programming.

Solid libraries for improving maintenance through encapsulating the how of your tests have been developed in open source frameworks such as WatirCraft and Page Objects. You would have to invest time to learn them but save so much time in the long run.
Page Object Gem: http://github.com/cheezy/page-object
WatirCraft Gem: https://github.com/bret/watircraft
Learning Page Objects: http://leanpub.com/cucumber_and_cheese

Best Locators for Elements in the Browser

In automated web application tests, we perform actions by manipulating objects or elements on the web page. We verify results by analyzing elements. These elements must be found first. The three ways to find them are by html locator characteristics, by the css (cascading style sheets) characteristics, or by the xpath (xml path) address of the element. The xpath addresses of elements are temporary identifiers, that make for fragile code. Because the address is according to directional instructions, the xpath is difficult to read as well. People I respect have made a case for using css at times. These characteristics are also subject to change and not easy to read.

Our best option is to stick to the html locators such as id, name, class, and/or link. My second option for times that those html locators are not providing me with unique, reliable identifiers is to talk to the development team. My favorite tool for reviewing the characteristics of the elements in the browser is Dev Tools/Inspect Element option that is bundled with the Chrome browser. I have also used Firebug for Firefox often.

Chrome Browser: http://www.google.com/intl/en/chrome/browser
Firebug plugin: http://addons.mozilla.org/en-US/firefox/addon/firebug

Conclusion

When web applications tests written with Watir use these principles, the tests are more successful because the cost of creating and maintaining is lower. We become more efficient by using the right tool mix. We have less failure confusion and result blockage by separating each test result. We build faster and maintain more easily using behavior-driven object-oriented frameworks. And we more reliably work with browser objects with good identifiers.
Some of these principles can be acted now. Others will require a plan to learn more about them, investigate how to implement them, and work through the details. Always be aware of which problems are caused by which principles you have not addressed.

About the Author

Dave McNulla has been testing software since 1993. He has used Microsoft Test for pre-web applications, WinRunner, TestPartner, and QuickTest Pro. In 2008, he started using Watir to build a test framework that was used for years. He also contributes to support forums such as Stack Overflow and the ‘Watir General’ group at Google Groups. Visit his blog at http://dmcnulla.wordpress.com/