In the last few weeks I’ve been presented with a new idea – a team that writes automated unit tests after the code has been fully implemented. Coming from a test first background the practice of writing unit tests seemed – just wrong.
If writing unit tests for your code is a good practice – than writing them before is even better.
When I inquired for the reason for writing code before tests I was answered that “writing the test before is hard and requires understanding of the code”, which means that unless you can predict the future writing tests for the yet-to-be-written code is nearly impossible - wrong again! claiming that in order to write tests you need actual code is just like saying that you cannot write user stories (or requirements) without implementing them first.
Don’t forget that the ‘D’ in TDD is stands for design – you design your code via tests not the other way around.
In fact writing the test after the code has been implemented is harder – you have to be very carful not to miss any feature and to write tests for every single line of code – a problem you don’t have when writing the tests first because you only write code that has a failing test.
The team that used the “test later” approach had another issue – they had a lot of dead code, methods and classes that were not even used or needed that were created because of some obscure requirement. because the feature was not really needed it didn’t have unit tests and just “rotted” over time. These methods would have never been created if test first paradigm was used.
From my brief experience writing the tests after the code is just harder and requires excellent memory and is mostly and exercise in futility. The end of this story is yet to be seen, in the meantime I’m teaching the team about TDD and I hope I can show them the benefits of writing tests as a design methodology…
Labels: Agile, TDD, Unit tests