While reading a book about Unit Testing I got caught on a small chapter about Test Driven Development (TDD). TDD is one of the most significant aspects in Extreme Programming and it’s core concept can be stated as “test twice, code once”. There is a three step procedure when programming:

1. Write a test on the new code and see it fail.
2. Write new code, doing \”the simplest thing that could possibly work\”.
3. See the test succeed and refactor the code.

The important thing most programmers must get used to is to write a test before writing complete and good code. Step two encourages programmes to keep their design simple and clean (as claimed by Extreme Programming) and make it more stable, intelligent and redundant after the test runs successfully.

Repeating this cycle is one of the most atomic levels of software development and it always has to be repeated when new code is written.

When debugging, this step is also a good approach: writting a test that fails because of the bug helps you to find out how the bug occurs. Following this step also forces you to think more clearly about your code and design before actually writting the first line of it. So writting tests is actually no debugging issue but an investment in good and clean code.