willbryant.net

What we want to test

Published Sun 11 November 2007 17:10 (+1300)
Tagged

This is part 2 of a miniseries of articles on Rails application testing.

So, we want to test the application we're developing. First we need to be clear about where our application starts and stops. From a high level, it's easy to see what a web application is – it's the thing that turns the dumb data store into a usable, functional interface, delivered over the net.

(Thass what happens when I start making slides late on a Sunday night after having friends over for dinner and a few drinks ;-)

Rails is an MVC stack
Rails is an MVC stack

Rails is an MVC stack, so it's natural to use that structure for our tests too. Usually, when people sketch out an MVC stack, they show something like this:

But views read from models...
But views read from models...

From a testing perspective, there's two things wrong with that picture.

Firstly, the views don't really go through the controller to get to the model – yes, the controller should pull out and create the model instances from the database ready for the views to use, but from then on the views do work directly with the models – the views are still coupled (to some extent) to the model since they expect to see certain attributes and walk certain relationships.

Easily fixed:

And browsers matter.
And browsers matter.

The second thing is a real killer. If you just tested your Ms, your Vs, and your Cs, you're only going to catch half the problems in your application, because you're missing out one of the biggest areas of pain – the browser.

While some developers are lucky enough to be working on apps where the browser can be expected to behave itself, for most of us, what goes wrong in the browser is fully half the battle.

This is especially true if there's a lot of AJAX or other “dynamic” functionality in your app – then there's not just the old layout and rendering problems to worry about, but also the innumerable differences between browsers and browser versions, not to mention the many not-quite-standard standards-compliance problems.

So when we talk about testing our web applications, we can't just stop hard at the edge of our server – we have to include the browser in our discussions. We'll cover this in the browser/acceptance testing section later in this series.

Next: MVC testing – This is where the bulk of most projects' testing time is spent. Covers RSpec vs. Test::Unit.

More