Last week, we had a lunchtime get-together to talk about refactoring the functional tests. This week, we had another conversation about “things that were really good” about the project. A little gem came up between them: CardSuites.

A CardSuite is a suite of acceptance tests which describe a story.

The acceptance tests run as fully as possible, from beginning to end. Now, we have a problem, which is that we’re not differentiating much between stories (ie: additions of features) and bugs (where a story has been misunderstood, or doesn’t fully work, or the story has changed slightly due to business requirements). They all get tagged with the universal “Change Request”, and they all get full acceptance tests written for them. Beginning to end. And this is a huge project – it’s no wonder our tests take 6 hours to run.

Most of the bugs, though, involve only a small deviation from existing behaviour. Writing an entire acceptance test seems like overkill. Sometimes a bug occurs because something’s not being tested – for instance, a message goes to two different systems in two different formats, and only one of them’s being checked. Sometimes it occurs becaue a series of events lead to the domain model being in an odd state. Sometimes it happens because a story is wrong, or being interpreted wrongly. So there are a few ways of automating the test for a bug fix which don’t involve writing end-to-end:

• add a check (or mini-test) to an existing story
• change an existing story to match new understanding (this doesn’t mean, say, changing it to test a more complex process and forgetting about the simple one)
• test the bit which deviates from an existing story.

The last is my favourite. Wouldn’t it be great if we could write a partial acceptance test which starts from a point we know we can get to without any bugs, and end at a point from which we know we can proceed?