The Focus of Watir

When developers I meet find out that I’m a project owner for both Selenium and Watir, the reactions are often similar. Most of them don’t know what Watir is, but have heard of Selenium. All too often they also tell me that they or their companies have used Selenium before, but didn’t find enough value to continue using it. They are usually right; the way many companies do test automation the costs exceed the benefits.

This is unfortunate because there is valuable information that can be obtained with automated user interface tests that can not be easily duplicated by other means. There are a number of ways to increase the benefits and decrease the costs, but Selenium itself does not, nor should it, help address these difficulties. This is where Watir comes in. As of version 6.0, all browser interactions in Watir are implemented with Selenium, so it is an add-on and not a competitor. The way that Watir adds to Selenium’s functionality makes it ideally suited to address the value concerns of test automation.

Selenium vs Watir
Selenium is a browser automation library. It supports a limited set of ways to interact with a browser (these ways are in the process of being defined as a w3c specification). It makes sense for this library to be minimalistic in the toolset it provides and allow room for third parties to customize the way they use it. Watir is a test automation library. It has the ability to extend basic browser automation functionality and provide tools to make it easier to write tests that work for the common scenarios found in today’s websites.

While transitioning from its original incarnation to using Selenium, Watir adopted a little too much of Selenium’s minimalistic approach. Watir should not merely be an implementation of the WebDriver specification with a different API from Selenium. Where Selenium facilitates browser automation, Watir needs to facilitate test automation. Where Selenium “does what I say,” Watir should “do what I mean.” Where Selenium limits what users can do with it, Watir needs to actively seek out ways to better accommodate users.

Current Response to Features
Over the past few years a number of feature suggestions and pull requests to the Watir project have been unnecessarily rejected. There have been a number of reasons given (many of which would be reasonable if this were the Selenium project) that are bad for the Watir project. The following points are paraphrased from various comments:

1. There’s already a way to do it. This is a great ethos for a minimalist library implementing a bare bones tool-kit. It is not a useful criteria for making it easier for users to write tests.
2. The developers should change the website code. There are situations where tests need to interact with applications that can not be changed, and it is a clear project smell when it expects other things to change to match its preferred philosophy, rather than making it easier for its users.
3. That’s not how WebDriver does it. Watir is not, nor should it be tied to the limitations of the Selenium project or the WebDriver specification.
4. There’s no good reason to add that to the project. User focused projects need to have a presumption of adding a user suggested feature unless there is a good reason for not doing it, rather than the other way around.
5. That can be put in its own project. Most Watir users are not going to be digging through other people’s gems to find features that would otherwise be useful to them. Either Watir should add code that technically could be put in another gem, or it needs to better facilitate the creation, documentation and publicization of that other gem.

Watir Priorities
Watir needs to be focused firstly on the user’s needs and secondly on encouraging the community that can help support the user’s needs.

1. Improve test reliability. Watir should focus on features and change its default behavior so that the most common causes of instability that a user faces are addressed automatically or more easily.
2. Make writing maintainable tests easier. It is costly to continually revisit test implementations, and also costly to write tests in a way that will minimize such future maintenance. Watir should make it easy to quickly write tests that are easy to maintain.
3. Help users become better programmers. Watir can be used as a tool to learn how to write Ruby code well. For the project this means focusing on good object orientation principles and promoting understandable code over clever code.
4. Make extensibility easier. Users should not have to override or monkey patch internal Watir code to successfully write their tests. If it is not the desired default behavior, then Watir should provide tools to customize the behavior in an officially supported manner.
5. Encourage Community Participation. Whether by code submissions or feature requests, the larger the group of people interacting with the Watir project, the more usable and useful the project will be. Watir should enthusiastically accept feedback and allow it to shape the project.

Feature Evaluation Criteria
Future pull requests and feature suggestions should be evaluated based on these criteria:

1. Does it support the purpose of project? Features should improve the user’s ability to test a website and follow the priorities described above.
2. Is there a demand for it? If there are Stack Overflow questions about it or blog posts showing how to create or work around a feature in Watir, then there is an established need for it.
3. Does it follow the Principle of Least Astonishment? Watir users shouldn’t be surprised by the results of the methods being used. The most obvious result should be supported.
4. Do the benefits outweigh the costs? Each extra piece of code in a project incurs some cost, but there is a big difference between an independent method that doesn’t change existing code, and code that will need to be continually cultivated as the project changes.

For automated user interface testing to maintain its relevance it needs to be more useful and less expensive for companies. Watir has the potential to properly address these concerns and be a model that other projects and testing frameworks can follow.

These are my opinions and do not necessarily reflect the opinions of the entire Watir team. If you use Watir or are interested in participating in the community, please leave a comment with any differing viewpoints or ideas or suggestions for how the Watir project should focus its efforts.