Recently I've been moving some code about in a project I'm working on in order to remove some duplicate code. While extracting the code I wrote a number of unit tests to validate that I was doing this correctly. As these tests were written for code I already had (I was primarily shifting it about, apart from a rather critical bug fix that prompted the original change) the tests reflected very much the structure of the code that I was moving.

In order to ensure that the functionality remained consistent I went back to the tests for the original, now deprecated, code and modified them to test the new structure. While doing so I was struck by the difference between them. The original tests were much more focused on the intent of the code, the new tests on its structure. Due to the nature of the change it wasn't really practical to adapt the original tests while extracting the code. However it would have been a loss to the system to have removed them as they expressed intent much better than the new tests so I modified them to work with the new code.

This is indicative of writing tests after writing the code. Inevitably what you get are tests that reflect the code as it is because it already exists and the tests being written solely to validate it. This may make the code easier to modify in future but you lose the design benefits of doing test driven development. Additionally tests that reflect structure rather than intent are more likely to be fragile if that structure needs to vary.

Writing your tests at the same time as the code is about more than validating its correctness. The tests will influence the design of the code. Code written using TDD will tend to be better factored by virtue of the fact that this is a requirement to be able to reach in and test it fully. As the unit tests form an initial client for your code you are more likely to detect errors or inefficiencies in your API and correct them early when it is still inexpensive. TDD also tends to act to reduce coupling be encouraging clear boundaries and abstractions so that each class may be tested in isolation. If you are writing your unit tests after the fact you will not get any of these benefits.

I refer to writing the unit tests "with" the code. Although some people insist that you must write the entire test before the code I remain unconvinced. Provided that you are writing them in an intermixed fashion, such that code segments and their tests are written together and that you will allow the requirements of the tests to influence the structure of the code then you are doing TDD. I do tend to prefer writing the majority of a test up front (or sometimes multiple tests up front), but this is not always applicable.