This is part two of my DBC vs. TDD ramblings, where I’ll be describing Test-Driven Development and why it’s A Good Thing.

My ideas about what TDD is seem to vary significantly from what is commonly known as TDD. I think this is a result of tools being developed that make automated testing and TDD really easy, but these tools being used almost exclusively for automating unit tests because as programmers we find it very easy to focus on the details and forget the bigger picture - and as a result writing automated unit tests has come to be seen as the way to ‘do TDD’.

So here’s TDD in my eyes - Which I think is well-aligned with the ideas Kent Beck puts forth in ‘Extreme Programming Explained’ and ‘Test Driven Development’.

Each piece of functionality you’re going to implement has tests written verifying that it meets the  outcomes required of it, before you even think about coding. What I want to point out here is that this doesn’t say “writing automated unit tests before you start coding”. That’s not TDD, that’s writing automated unit tests before you start coding. Maybe it’s ‘unit test driven development’, which is a subset of TDD - But this isn’t something you want to do at the outset.

We start TDD by defining the acceptance tests we’re intending to satisfy (i.e. the user stories we’re going to implement). We can automate these tests, or we can not. That doesn’t matter. What matters is that we’re using these acceptance tests to drive our development, rather than using what we’ve developed to write our acceptance tests. Doing this lets us know when we’re finished - The moment our acceptance tests pass we can confidently stop developing.

This is the part of TDD that is often forgotten, and which has started popping up under other names, including ‘acceptance test driven development’ and (I would argue) Dan North’s ‘Behaviour Driven Development’.

Once we’ve defined our acceptance tests we can start to think about implementation. When we do that we’ll probably want to write unit tests for our modules before we start writing them. Just like with design by contract, this helps us to step back and understand exactly what we’re doing as well as providing a way to know when we’re done.

This - the final part of TDD - is what now seems to be considered as the whole of TDD, and this is where we use defined (and perhaps automated) unit tests to drive the development of individual modules.

Next week I want to bring together TDD and DBC to see where they intersect and what, if anything, is offered by one methodology but not the other.