Watir History
Watir grew out of Ruby code written by Chris Morris in 2001 to control Internet Explorer through its COM interface.(1) This library was called cliec. In 2003 Bret Pettichord and Brian Marick began using this code as the basis for a course they were teaching on test automation. Inspired by this course, but needing something capable of working with more advanced websites, Paul Rogers created his own library and called it WTR (Web Testing in Ruby).(2) This library had more functionality but a poorer API. Bret and Paul got together at the Agile XP conference in August of 2004 to take the best parts of cliec and WTR and created a cleaner API using TDD principles.(3) The first commit with the new name is from September 30, 2004.(4)
From the earliest days of the project Watir has had people dedicated to building a community around it. This endeavor has been mostly independent from writing the code. Early on this was handled by Jonathan Kohl who took on the role of writing the initial documentation, creating code examples and guides in addition to general promotion. Other people filling this role over the years includes Chris McMahon, Zeljko Filipin, Alister Scott, and David McNulla.
Bret joined ThoughtWorks in 2004 and was introduced to the work Jason Huggins was doing with leveraging JavaScript in the browser for testing using a program that was initially called JavaScriptTestRunner, and would eventually became known as Selenium.(5) Fun fact: Jason made a list of potential names for his project, but when ThoughtWorks needed to present an agenda that included discussing this technology at a conference in Australia, Jason wasn’t available to provide the official name. Paul Hammant and Bret looked at the list, and Bret’s background in the QA community caused him to recognize the humor in calling the project Selenium. The primary expensive commercial UI testing solution at the time was owned by Mercury Interactive and Selenium is known to be a cure for Mercury poisoning. Jason returned to find his project named for him, but it’s certainly proved to be an excellent brand name.
Original versions of Selenium were focused on being a test framework with its own HTML table based Domain Specific Language (DSL). It had some technological limitations and issues with flexibility, as well as offering multiple ways of doing similar things. Its big advantage was its support for all of the various browsers that were starting to steal market share from Microsoft. To keep up with Selenium, various groups created browser specific projects for Watir including FireWatir, OperaWatir, SafariWatir, and ChromeWatir).
Selenium also had the advantage of easily supporting development in multiple programming languages. As a result, Watir was also adapted into Java with Watij and .NET with Watin.
WebDriver was created by Simon Stewart in 2007 (also at ThoughtWorks at that time) and it provided solutions to some of the major issues Selenium faced. Rather than applying a single JavaScript implementation for all browsers, it required creating a unique driver for each browser that would have more power and flexibility. The code base boasted a cleaner API and was less of a testing framework than a toolkit of direct browser automation commands.(6)
As the WebDriver drivers matured, Selenium found the WebDriver solutions appealing enough to agree to merge the projects. While Selenium 2.0 effectively emulated Selenium 1.0 (RC) for backward compatibility, adopting WebDriver’s object oriented driver approach required significant code updates. Since Watir had always used the “driver” approach, Watir users ironically had much fewer adjustments to make in their code than Selenium users did in order to be able to leverage the full power of WebDriver.
When Jari Bakken, a Watir developer, was exposed to WebDriver in 2009, he began developing a Ruby implementation of it for both Selenium and Watir. Jari had already written Celerity, a JRuby project to implement a wrapper for HtmlUnit, to provide a headless testing option with the same API as Watir. With his work on watir-webdriver, he decided to take the Celerity specs and make them usable for both projects.(7). In doing so he created the WatirSpec repository which could be used by any of the Ruby-based projects that implemented the Watir API.
The functionality being provided by WebDriver caused the Watir team to add features and change its conventions when it made sense to do so. The big backward-incompatible change in the Watir 2.0 (released in August of 2011) was the move from one-indexing to zero-indexing. Indexing “like a person” makes sense until you have to constantly figure out if you are working with a Watir Collection or a Ruby Array (or with WebDriver). The challenge of bringing Watir into complete compliance with the WatirSpec was taken up by Jarmo Pertman and culminated in the release of Watir 3.0 in April 2012.
To encourage the use of watir-webdriver, Hugh McGowan renamed the Watir code base “watir-classic” and created a “meta” repository that would default to using the watir-classic implementation for Internet Explorer and using the watir-webdriver implementation for all other browsers. This code was implemented by Jarmo and released as Watir 4.0 in Sepetember 2012.
In January of 2015 Jari decided to step down as maintainer of the selenium-webdriver and watir-webdriver gems.(8). Alex Rodionov had been an active contributor for the previous three years and took over primary ownership of the project with assistance from Titus Fortner. Titus was working with Bret at Blackbaud at that time and had just been officially added to the development team.
With Microsoft releasing the Edge browser and announcing that no new features would be added to Internet Explorer, the need for the watir-classic code to be actively maintained dramatically diminished. Also at this time there was significant confusion around what Watir was and what gems should be used; it was not uncommon for Watir users to say they were running with “Watir WebDriver, not Watir.” Since the tester-focused API has always been the key distinguishing feature for Watir, not the implementation, the project needed to refocus and disambiguate. In 2016 Titus spearheaded this move, deprecating both watir-classic and watir-webdriver gems and releasing Watir 6.0 with a new logo, a new website and an updated version of the Selenium-backed code. Based on numerous conversations with Bret about the original ideology behind Watir, Titus updated Watir to become less like an alternative implementation of Selenium, and to more fully leverage the Watir API to remove extra configurations and add default waiting behaviors that better adhered to the original spirit of Watir.
Instead of being a competitor to Selenium, Watir 6 relied on the Selenium code for the browser automation capabilities of WebDriver. Think of Selenium as a Browser Automation Library and Watir as a Test Automation Library. Selenium provides the means for a user to interact with a browser with a “do what I say” approach, whereas Watir leverages Selenium to allow a user to accomplish a “do what I mean” approach to testing the UI.
Soon after the release of Watir 6, a Sauce Labs user complained about how much slower Watir was performing on that platform. Titus had recently started working at Sauce and found that there were indeed a lot of performance improvements that could be made. The various 6.x releases mostly consisted of eeking out as much performance optimization as possible while still providing the same reliability. Various new and interesting functionality was added over time. Not much development was done on Watir after the final version of Selenium 3 was released until Selenium 4 was released as a beta in early 2021. Watir 7.0 was released the week after Selenium 4.0 in October 2021.