In my last post about Cucumber, I alluded to using watir-webdriver instead of using native watir. There was one very surprising advantage I discovered with watir-webdriver's use of selenium as a backend: Awesome Screenshot API.
Here's how we setup our Cucumber suite to take screenshots (and html/txt "screenshots") using watir-webdriver and celerity. First, set your tests up to write an error when a test fails:
In this hook, we're passing in an environment, the scenario and the browser object we setup in the prior post. The environment is really handy since QA folks might be running tests against different regions and would want to pass that information back to the developers to recreate problems. The TEST_SERVER environment variable is already used to pick this during test startup.
The ErrorWriter module is next.
Several things are going on here. The write errors message is simple enough. It creates a directory for the errors to be written, and dumps the context of the browser's text and html representations to file. What's more interesting are the scenario_name and file_name methods.
The scenario_name method does some interesting things. We want to name our files by the name of the scenario that fails. In the else clause, you see how dashes and white space are replaced by a single white space character. But, in the if clause, we're testing to see if we have an ExampleRow. These are the Examples in a Cucumber Scenario Outline. If the scenario is an ExampleRow, we lose the name of the Scenario itself. Fortunately, the ExampleRow knows what ScenarioOutline it belongs to. We can get the name of the ScenarioOutline, perform the same transform on the name, and then append the example that is actually running to it's name.
The file_name method simply concatenates the region, time of failure and the scenario name together for the filename to be written to.
This can result in some very long file names, however, their descriptiveness wins overall. You don't have to open a file to find out what failed. A simple reading of the directory containing the files lets anyone find the test that they need to examine quickly.
The write_errors method did one other thing. Call capture_screenshot to grab an image of the browser. When using Watir, you had to do some fancy things with the Win32 API to make the capture work. We had a lot of issues using it with our QA folks who had SnagIT installed. So how refreshing it was to have watir-webdriver just work with so little code:
We have another little trick, where in our prior example, we setup a WEBDRIVER variable to determine if we could take a screenshot. If we're running on Celerity, no harm, no foul, but no screenshot.
Granted, it's really selenium that we're using here, but we get really nice and small png files, which only contain the contents of the browser. No title bar, no toolbars, nothing. Just the contents of the window. Our only issue is that IE causes problems on our CI box, but just having Firefox able to run there is an outstanding step forward.
Hopefully this is helpful, please let me know if it is.
Semi-Random thoughts on life, computers, sports, and what not....but mostly programming.
Wednesday, April 13, 2011
Wednesday, April 06, 2011
Cucumber with Celerity and Watir-Webdriver
Earlier this year, I had the problem of trying to enable our QA staff to run our current suite of Celerity driven Cucumber tests through the actual browsers that we were using. One obvious solution is to use various flavors of Watir.
The main concern with this solution is that Waitr required native ruby instead of jruby. Not a huge deal, but still an extra annoyance for folks in a java shop. Requiring QA to switch between jruby and watir wasn't ideal. Additionally, taking snapshots of the screen during a failed test was far from trivial.
So instead, I embarked on a quest to use watir-webdriver and Celerity together. The advantage here is that watir-webdriver, through selenium-webdriver, can talk to browsers and runs on jruby. This combination was alluded to on several blog sites that I had found, but I never quite found something that put it all together for me. Eventually, i got it working. Hopefully this will at least get you about 90% of the way there.
The first step would be adding watir-webdriver to your Gemfile:
Following that we create a browser.rb file that determines what sort of browser you are running. I placed this in the support folder in the Cucumber project. One thing to remember about this, is that you could also throw this method into your env.rb.
What's going on here? We're using the environment variable BROWSER to determine if we want to run something in a browser. We then use another environment variable to determine which browser to use. We even have an environment variable to determine what Firefox we want to use, which is a nice feature of selenium-webdriver. At the end, Browser contains the class of browser we want to instantiate for tests, and BROWSER_TYPE contains the actual type of browser to instantiate for watir-webdriver.
One other thing to note, when we use Celerity, we're setting the offset for index based searches to 0. Unlike watir-webdriver, Watir uses 1th based arrays. Celerity, being a wrapper of HtmlUnit, had to translate those arrays from 1 to 0 so that HtmlUnit would run properly. By setting this value, we can use 0th based arrays, just like watir-webdriver does in Celerity.
Next we setup our Cucumber Before block in hooks.rb:
In here, we simply instantiate the object. In my case, we also needed to setup some URLs and turn off SSL for our Celerity testing.
The Rakefile is probably a bit more complex due to our desire to run both headless and browser tests on our CI box, but it is helpful, since it uses the :browser task to setup the BROWSER environment variable.
Finally, to help our QA folks, three batch files to execute the tests.
Hopefully you'll find this useful. Please let me know if you do.
The main concern with this solution is that Waitr required native ruby instead of jruby. Not a huge deal, but still an extra annoyance for folks in a java shop. Requiring QA to switch between jruby and watir wasn't ideal. Additionally, taking snapshots of the screen during a failed test was far from trivial.
So instead, I embarked on a quest to use watir-webdriver and Celerity together. The advantage here is that watir-webdriver, through selenium-webdriver, can talk to browsers and runs on jruby. This combination was alluded to on several blog sites that I had found, but I never quite found something that put it all together for me. Eventually, i got it working. Hopefully this will at least get you about 90% of the way there.
The first step would be adding watir-webdriver to your Gemfile:
Following that we create a browser.rb file that determines what sort of browser you are running. I placed this in the support folder in the Cucumber project. One thing to remember about this, is that you could also throw this method into your env.rb.
What's going on here? We're using the environment variable BROWSER to determine if we want to run something in a browser. We then use another environment variable to determine which browser to use. We even have an environment variable to determine what Firefox we want to use, which is a nice feature of selenium-webdriver. At the end, Browser contains the class of browser we want to instantiate for tests, and BROWSER_TYPE contains the actual type of browser to instantiate for watir-webdriver.
One other thing to note, when we use Celerity, we're setting the offset for index based searches to 0. Unlike watir-webdriver, Watir uses 1th based arrays. Celerity, being a wrapper of HtmlUnit, had to translate those arrays from 1 to 0 so that HtmlUnit would run properly. By setting this value, we can use 0th based arrays, just like watir-webdriver does in Celerity.
Next we setup our Cucumber Before block in hooks.rb:
In here, we simply instantiate the object. In my case, we also needed to setup some URLs and turn off SSL for our Celerity testing.
The Rakefile is probably a bit more complex due to our desire to run both headless and browser tests on our CI box, but it is helpful, since it uses the :browser task to setup the BROWSER environment variable.
Finally, to help our QA folks, three batch files to execute the tests.
Hopefully you'll find this useful. Please let me know if you do.
Subscribe to:
Posts (Atom)