I recently posted about my experiences of testing last where it became clear to me how important writing the test before the code is.

If we view the tests purely as a way of determining whether or not our code works correctly for a given set of examples then it doesn’t make much difference whether we test before or after we have written the code.

If on the other hand we want to get more value out of our tests such as having them the tests act as documentation, drive the design of our APIs and generally prove useful reading to ourself and others in future then a test first approach is the way to go.

Testing last means we’ve applied assumption driven development when we wrote the code and now we’re trying to work out how to use the API rather than driving out the API with some examples.

In a way writing tests first is applying the YAGNI concept to this area of development. Since we are only writing code to satisfy the examples/tests that we have written it is likely to include much less 'just in case' code and therefore lead to a simpler solution. Incrementally improving the code with small steps works particularly well for keeping the code simple.

As Scott Bellware points out, the costs of testing after the code has been written is much higher than we would imagine and we probably won’t cover as many scenarios as we would have done had we taken a test first approach.

I think we also spend less time thinking about exactly where the best place to test a bit of functionality is and therefore don’t end up writing the most useful tests.

Obviously sometimes we want to just try out a piece of code to see whether or not an approach is going to work but when we have gained this knowledge it makes sense to go back and test drive the code again.

As has been said many times, TDD isn’t about the testing, it’s much more.