litany against fear
RailsConf 2009 Webrat Rails Testing Evolved
This is part of my series of notes on RailsConf 2009. Check them all out here.
This talk is from Bryan Helmkamp.
Webrat = Ruby Acceptance Testing for Web Applications. Let’s say you’re creating a form: you want to know the code works as expected, and you want to ensure it still works when you make changes. The solution: writing tests.
Integration testing is built into Rails, and it does plenty of stuff already: creating requests, checking responses, determining what is on the page, and submitting the form on the page as well. It definitely works, but it’s verbose and requires way too much work. This is why Webrat was started: to make this process easier so people actually use it and want to write it.
Webrat has a very conversational tone, it’s like walking someone through the website. The basics:
visit [path]: Pretty much the same as the traditional Rails way of loading the page.
click_link "name": Uses Nokogiri to search through all of anchor tags and finds the link with that text. It then finds the href and it will follow whatever path is given. It’s a “browser simulator”.
fill_in: Finds the input you’re referring to and simulates actually entering information in, but without a browser.
click_button: Submitting form, which infers what URL to post to by looking up the form element it’s scoped to.
Getting started: Hook up the gem, some inital setup for your environment and you’re set. The core API is pretty small, and it’s all you really need to work with most web forms on a daily basis. It’s also test framework agnostic, and can even be used in IRB. It’s mostly used with Cucumber now, but what’s important is that the two are separate. There’s adapters for the big web frameworks: Rails, Merb, and Sinatra.
Some of the magic with Webrat happens due to the locator strategies. Usually it’ll just work, and especially with forms it can work off of a label tag with a for attribute. There’s also other ways to get elements if you need a less…magical way.
Webrat is meant for testing web apps, and checks all of the following:
- Verify HTTP status codes
- Verify form fields exist
- Verify HTML content
Plenty of awesome matchers/assertions baked in:
contain: Checking text in the response body.have_selector: Ensuring elements are on the page with the given CSS selector and some attributes/content if specifiedhave_xpath: Pretty obvious, a bit more powerful. Neat fact: Nokogiri actually converts CSS selectors to XPath.
Debug with save_and_open_page, which opens a temporary file of what Webrat is looking at.
There’s also adapters for Selenium and Mechanize adapters. It can be used outside of the verification context. The Mechanize session object can be used for screen scraping for example. This is being used by some to test existing web apps in other languages that want to convert to Ruby slowly, and the tests still work just the same during the process.
Selenium is now fully supported with Webrat. The library handles booting up both a Selenium and Rails server for you. It’s pretty easy to use the standard Webrat API and drop into Selenium when you need to. The main problem here: it’s SLOW. Get around this by writing only what’s necessary in Selenium, since Webrat itself is way faster.
Rack is going to help a lot with cleaning up Webrat, since they don’t want to maintain adapters for every Ruby web framework out there. This is what Rack::Test was created for, and it will hopefully be integrated in for Rails 3.