The Year of Programming Dangerously: Why View Testing Should Never Be Overlooked
An interesting thread on LinkedIn's Ruby on Rails Group and the Ruby on Rails blog reminded me of the importance of testing the output from your controllers.
If you've been paying attention, you may have noticed the unusual number of Rails releases (2.3.6, 2.3.7. 2.3.8) deployed in rapid fashion recently. It turns out the reason behind this was a bug caused by back porting of some XSS protection features from the upcoming Rails 3. And it turns out that those bugs went undetected because of a lack of comprehensive view tests in a Rails module.
There are several ways you can approach testing the output from your application controllers, such as:
- In your functional tests, using assert_select on the output (or alternatively, searching for patterns or substrings).
- Writing RSpec tests that mock your output.
- Using Webrat to examine output.
- In Selenium or Watir, by searching and examining elements in the output.
What I find puzzling is that few developers, including myself, bother writing view tests at all. Yet the application output can often be the source of many common bugs that are not easily detected visually, such as form parameter name mismatches, incorrect field state settings, JavaScript typos from AJAX actions, and element visibility (or invisibility) issues.
So why is this? There are two possible factors that come to mind:
- Lack of view testing examples in popular screencasts and blog posts that cover testing. I won't name names, but several tutorial screencasts that cover testing frameworks simply ignore or eschew view testing and don't offer examples. Because software developers learn by imitation, it lends to a culture that suggests that view testing is an esoteric facet that doesn't require much attention.
- Cumbersome API's. The assert_select method, and XPath for that matter, are painful to use. I have a hard time testing output without having the assert_select cheat sheet in hand.
What Rails needs is a more abstract set of built-in APIs for examining HTML output in an abstract and object oriented manner, particularly for important interface points such as form field parameters and state, and style directives on elements, especially with respect to visibility.
And while testing your UI interactions using Watir or Selenium can sometimes cover the same area, it's important to note that running these tests tend to be slow. Functional or view tests, on the other hand, can be run repeatedly and quickly without waiting for the browser set-up. Same goes with Webrat.
If anyone has suggestions on gems or plugins to make view testing easier, I'd love to hear them.
Trackbacks
Use the following link to trackback from your own site:
http://stardragon.com/trackbacks?article_id=19
Comments
- Very interesting post. Honest.
- View tests are hard. They are so hard, that I barely even write them. I don’t leave my views untested though. I find that using capybara (or webrat) through cucumber makes views much easier to test. If you factor in cucumber’s table support, you will have a much easier time if you go this route.