Not Testing Views, How Jay Tests 18 Sep 2007
Jay Fields mentions in his post “How We Test”:http://blog.jayfields.com/2007/09/rails-how-we-test.html that he doesn’t write view tests.

View tests, in my experience, aren’t necessary unless you are putting logic in your view. I prefer to keep the logic out of the view and ignore view tests entirely.

I agree with a lot of what Jay blogs about, but this I don’t think I do, but it’s hard to say because he didn’t post any context or information about his statement.

Although Jay has a point in keeping logic out of the view, view tests themselves are still an important aspect of testing rails applications. Here’s why I think you should test your views:

Integration tests should be lightweight and very high level (customer readable or as close as you can get to it)

If a customer wants information A, B and C to be on page foo then you need prove that A, B and C show up. Here you can use a view test! (An integration test would test going through the application, but view tests would test the details to make sure the right information is on the page.)

Controller/functional tests should not test anything view related, so this requires a separate view test

View tests may help keep your views organized and manageable

View tests encourage the use of using helper objects/methods because you don’t want to write tests to test logic in the view. If you don’t test your views it’s easier to put logic in there.

The thing that makes me want to keep view tests are that, if a customer says I want to see this information, then it is my job to prove that it show’s up. There are three options for this:

Put the testing of that information being displayed in your controller test. (this is painful!)

Put the testing of that information being displayed in your integration test. (bloats your high level customer readable integration test. I want to avoid this bloat at this level!)

Put the testing of that information in it’s own isolated view test (my preference of choice!)

YMMV based on your project. It may also vary based on your team setup and chemistry. On my current project the developers work with a HTML/CSS Builder to build the whole site. Several times we (our developers and HTML/CSS builder) have made pieces of information or links disappear when updating views. Without our view tests we wouldn’t have caught it as early on.

I have heard an argument against view testing which has to do with the cost of writing and maintaining view tests against the cost of letting developers, testers or customers find them. The argument is that “it’s cheaper to not write a view test and let someone find a bug rather then to write a view test and fix something before someone finds a bug”.

I disagree with this because I think there is a lot of risk involved with letting precious information slip through the cracks. Web applications these days often involve a lot of views and a lot of information. The whole point of test automation is to not require that someone remembers to test everything. Automated view tests are faster, they never forget a piece of important information to look for and they don’t require that anyone remembers everything that needs to be displayed.

There are ways to test your views which makes them feel unnecessary, brittle and painful, but this can be avoided. You can have easy, meaningful view tests which add value to your project for your development team and for your customer.


blog comments powered by Disqus