Testing your views is often the brunt of many jokes in the Ruby community. The importance of view testing is starting to make a come back with things like Cucumber and Webrat, but I’ve been thinking more and more that testing your views is about content. We’ve recently started a redesign at my current job and I decided I would attempt to achieve view zen by writing absolutely no code until my specs told me to do so.

I wrote some view specs to assert what content should be shown on a particular template and made them pass. Pretty easy stuff. Here’s an example:

Done and done.

After writing a number of similar looking specs for other pieces of information on a Business I was not sold on their usefulness. It seemed like I was traveling down a testing path that was useful to give me direction, but not necessarily flattening the cost of change in the future.

But wait, why do I even care that there is a <span> tag with the business’s name it? The truth is that I don’t and neither do any of the stakeholders. The stakeholders care that the view looks correct and displays the content correctly. View specs like these aren’t valuable to anyone but developers. They don’t actually describe anything about this content. I started to wonder if I was actually making my successors’ jobs harder by writing such rigid specs. I decided I would continue to write view specs but with an intention of describing the content being displayed. The next set of specs I wrote looked a little more useful. I’ll modify the previous example to demonstrate what I’m saying

Great! Now this spec actually attempts to say the markup should attempt to describe its content. I was feeling much better about this approach and happily adding ids, classes, and markup meant for the content. I felt like I actually understood why I should not write HTML for a browser, but rather to markup my content.

Once I had finished the specs for the views a new story came along asking to implement the hReview-aggregate microformat. This meant that I was actually supposed to be testing specific classes and tags on the content. Here’s an example:

After finishing that up and discussing the approach with @nolman and @drewolson I came to the conclusion that view specs are great if you need to describe your content. However, even if a stakeholder is not asking for microformats they are a great way to structure content.

In the future I’d like to try writing my view specs with microformats in mind first. If you’re having trouble understanding why this is actually easier than ad-hoc view testing then I would recommend you read an http://errtheblog.com/posts/53-microformathingies He talks about removing Chowhound’s API in favor of semantic markup in HTML. I don’t necessarily think a REST API (via JSON or XML) and semantic markup should be mutually exclusive, but the idea that you can test your markup through parsable microformats means you can have more confidence that your content is meaningful to your customers and consumable by machines.

I might want to say something like this rather than testing view specs using have_tag and with_tag.

You get the idea. I think this may be possible with Mofo and some custom rspec matchers.

Resources on view specs:

• http://www.robbyonrails.com/articles/2007/08/02/spec-your-views
• http://errtheblog.com/posts/66-view-testing-20
• http://rspec.info/rails/writing/views.html

Resources on microformats:

• http://microformats.org/wiki/Main_Page
• http://mofo.rubyforge.org/
• http://microformats.org/wiki/hreview-aggregate
• http://slideshow.rubyforge.org/microformats.html
• http://www.google.com/webmasters/tools/richsnippets