Welcome to Dovetail Software Blogs : Sign in | Join | Help
Goodbye Selenium, Hello Watir

After a 1.5 months of using Selenium, the team decided to bring in Watir.  There were several reasons for our decision, which I'll outline:

1) The testing community is going towards Ruby.  Ruby has turned out to be a very friendly language for the test community.  Brian Marick's new book titled Everyday Scripting with Ruby, For Teams, Testers and You is a direct reflection of this.  I attended AWTA in January and all of the presentations showing test frameworks/examples were in Ruby, with the exception of a Java example.  Yes, I know Selenium uses Ruby, but...

2) The Watir API is richer and contains deeper functionality than the Selenium API.   I don't know the entire history of Selenium, but I do know Watir was written by a tester for the testing community after finding commercial tools were lacking (thank you Bret Pettichord).

3) In our adoption of Selenium, we were using StoryTeller, which is a FIT-like acceptance test tool , which uses the Fitnesse engine.  (We still plan on using Storyteller for validating the workflow.)  We were using Storyteller to drive our UI and API data-driven tests.   This meant that developers wrote fixtures that contained Selenium scripts using C#, which meant introducing a layer of abstraction to the test team.  With Watir, the test team is writing these UI tests, allowing developers to focus more on TDD.

Regarding dual browser compatibility, we have a story card that mandates our application should work with IE and Firefox.  So, why are we choosing a tool that only works with IE?  We came up with two solutions for that question.  First, the team is going to be cognizant of the fact that some tests will need to be tested in Firefox, which could require some reworking of the script in FireWatir.  And secondly, most of the team uses Firefox as our default browser.  We would already be validating that the UI works within Firefox.  In essence, we are testing the IE browser.

This is an example of how working on an agile team allows us to make necessary changes mid-production in order to deliver a higher quality product.

Posted: Friday, March 23, 2007 7:58 AM by jdarling
Filed under: ,

Comments

jason darling said:

# July 5, 2008 6:37 PM