04 July 2007

Start with a working system

Image we've just been commissioned to build a system, we have 30-inch monitors, we have the Customer in the room, we've prioritised some stories, now let's write a unit test! Well, maybe not yet. Our first test should be an attempt at something end-to-end that exercises a visibly useful feature (even if it's really, really tiny). To make this test pass, we'll need a Walking Skeleton, an absolutely minimal sliver of the whole system that actually works. To make the Walking Skeleton work, we'll have to think about the structure of the system, including build and deployment, which will help us flush out a whole Sackful1 of project risk: our chosen messaging system doesn't work on our chosen platform, we need 4 weeks notice and 8 signatures to make a change to production, the target PCs only have 640K of RAM, and so on.

As a rule, we only discover this sort of issue when we actually try it, which is why we like to start with a build and deploy script, and then figure out what to put in it. We also prefer deploying as close to production as possible, since each step in the end-to-end journey brings its own challenges. This approach means we find the blockages at the start of the project, when we still have time to fix them, rather than at the end. In practice, of course, sometimes these steps take so long to implement that we start with a shadow system to stand in for our current interpretation of the real thing. But this is only a stop-gap, a temporary patch to allow us to make progress, it's not an acceptable end solution.

We need to make the point more strongly that unit-level testing (even using mocks!) should take place within the context of higher-level tests that set the direction for the current slice of development. The higher-level tests keep us focussed on what we need to implement next and keep us honest about what is working.

1) that's a level-2 Sackful, as defined in the PMBOK.

1 comment:

Jamie said...

Indeed. I think this is where many people get confused about the different levels test driven development can work at. Even using RUP you can augment use cases with accetpance tests and they become a way to do TDD.