5 reasons to use Test Driven Development (TDD)

1. A unit test with a coverage of 80 % sounds good, but the coverage is only verification that the code follows the specification / design. If the specification / design don’t solves the necessary needs, then both the implementation and the unit-tests would be an unnecessary expense. TDD can help you validate the design and not only verify the implementation of the code.

2. Bad code is okay, because some developers are better at solving problems than others (bad code is better than no code). Other deveopers are better at cleaning the code, making it easier to understand. A third group is better to optimize the code. A forth group is better at making the code more secure. TDD can help each developer, to use their own “super powers” to improve the code.

3. Debugging is a method, where you verify that the code behaves as expected. TDD can secure that the verification is written down, so you and other developers can reuse it later.

4. Documentation should be short, accurate, understandable, and up to date. Sadly, one or more of the properties are often lacking. TDD creates documentation in the form of working code examples (unit-tests), which are easier to understand than cryptic and abstract theory-crafting (there is a reason why Stackoverflow is so popular).

5. Given the benefits explained above, it would be unprofessional not to adopt TDD