I’m sure you have already heard of Test Driven Development or TDD since it has been introduced in the Extreme Programming (XP) methodology in the late 90’s by Kent Beck. This development process relies on a 3 parts cycle : Red – Green – Refactor. You start by writing a unit test that fails (red) because the tested code does not yet exist. After you write the code for your application that makes the test pass (green) and then you can refactor your code to remove code duplication and others code smells.

In “The Clean Coder” Robert Martin defines 3 laws of TDD :

1. “You are not allowed to write any production code until you have first written a failing unit test.”
2. “You are not allowed to write more of a unit test than is sufficient to fail – and not compiling is failing.”
3. “You are not allowed to write more production code that is sufficient to pass the currently failing unit test.”

By following these 3 laws you are locked into a cycle that force you to test every aspect of your code and to fully follow the TDD principles.

Having a full test suite allows you to have the control over the behavior of your application and to avoid any regression after a bug fix or a refactor. The other benefit of having tests is that it provides a detailed documentation for every piece of your program. Each test gives information about the behavior and the expected result of the feature it tests in a given context.

I have to admit that, when writing these lines, I don’t use TDD. Why ? I don’t really have any excuse for not doing it. But I believe in the fact that TDD is a helpful process. I have to practice it in order to absorb it into my everyday development process.

See you next time for “Practicing“ !