Red Squirrel Reflections
Dave Hoover explores the psychology of software development
|
|
Tue, 25 Apr 2006Watir, the Lazy Programmer's Friend My current client was in need of a functional test suite for their web site to raise our confidence that we wouldn't break anything when we upgraded to Hibernate 3. Despite being a Selenium fan, I wanted to give Watir a try (for various reasons, it felt like a good fit). People were hesitant about the introduction of a new language (Watir is a web testing DSL in Ruby), but after I spent a day getting a bunch of test scenarios scripted, Watir proved its worth. Every developer I paired with said the same thing: "I'm never going to type into a browser again." There were things I could do with Watir that I would be hard pressed to do with Selenium, like outsmarting CAPTCHA, abstracting common code by opening Watir::IE, and switching between dev, test, and staging by changing a single variable. That last point is one of the big wins of Watir over Selenium, you never touch the server, it's dead simple to setup. That said, the achilles heel of Watir is that it currently only runs on Windows and IE, while Selenium runs virtually anywhere on any browser. So I'll stick with Selenium for my Rails project on my MacBook, while Watir seems to be a good fit for our Windows workstations at my client site. Abstracting common code into Watir::IE has worked beautifully so far. We created a WatirHelper module that includes code like this: module Watir class IE def login_admin text_field(:name, "name").set("jerryQ") text_field(:name, "pass").set("bletch") button(:name, "Sumbit").click end def fill_out_problem_form(last_name, email) select_list(:name , "dateMonth").select("December") select_list(:name , "dateDay").select("25") select_list(:name , "dateYear").select("2008") text_field(:name, "firstName").set("F") text_field(:name, "lastName").set(last_name) text_field(:name, "email").set(email) text_field(:name, "confirmEmail").set(email) end end endWhich allows our Watir scripts to look like this. require 'watir' require 'watir_helper' include Watir # update this to point to any server you want server_name = "localhost" ie = IE.new ie.goto("http://#{server_name}/admin") ie.login_admin ie.link(:text, "Tell us your problem").click ie.fill_out_problem_form("Foo", "foo@bar.org") ... assert ...Over time, we had become so lazy (thanks to Watir) that we couldn't tolerate filling out the lengthy forms on the site when we needed to try something out but didn't want to run the tests. So we developed some smaller scripts that didn't test anything, but would fill out forms and click through a series of pages so we could get on with the more interesting stuff. This worked beautifully, mostly because we had already removed enough duplication to give us coarse-grained operations with which we could construct short, powerful scripts to do our bidding. But then I got tired of running scripts. I wanted a Watir dashboard. Ruby/Tk to the rescue! Here's my quick spike of how to drive Watir from a GUI. require 'tk' require 'watir_helper' root = TkRoot.new { title "Dashboard" } button = TkButton.new(root) do text "Start Google" command proc do ie = IE.new ie.goto("http://google.com/") end end button.pack Tk.mainloopIt took me a couple more minutes to get a real dashboard up and running and now I can drive around my client's webapp with a push of a button! [/projects/watir] permanent link Just capture requirements as fake Ruby code One of Kent Spillner's reflections on Rich Kilmer's talk at the Silicon Valley Ruby Conference... He spent the first day on the project pairing with the domain expert, writing everything they said in Ruby assuming the DSL already existed, and then spent the remainder of the project back-filling what was needed to make the DSL work and building the UI. via ObieMostly posting this to remind myself that now is the time to adopt this approach. |