Test Driven Development (TDD) Concepts

Test-driven Development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved so that the tests pass. This is opposed to software development that allows software to be added that is not proven to meet requirements.

American software engineer Kent Beck, is credited with having developed the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

TDD is related to the test-first programming concepts of Extreme Programming, begun in 1999, but more recently has created more general interest in its own right.

TDD Cycle Example

TDD Cycle
Clean Tests
Tools

TDD Cycle

As with the image above, the cycle is defined in 5 steps, there are also 3 phases in TDD:

Write test(s)
Check if tests fails - Run the test(s) to see if it fails. It it succeeds, go back to 1.
Write the code - If the test fails, write the code.
Check if test(s) are okay - If it fails the go back to 3.
Refactor Code - We have an article on this. After you refactor, you repeat at 1.

The TDD has 3 phases:

RED - First write a unit test in failure. The impossibility of compiling is a failure.
GREEN - Write as soon as possible the production code sufficient to pass this unit test even if it means allowing the "worst" solutions. Of course if a clean and simple solution appears immediately, it must be realized but otherwise it is not a serious the code will be improved incrementally during the refactoring phases. The aim here is to obtain as soon as possible the green bar of success of the unit tests.
REFACTOR - This phase is often neglected but is essential because it eliminates possible code duplicates but also makes it possible to make changes in architecture, factorization, presentation... This refactoring concerning both the production code and the test code and must not modify the external behaviour of the program, which is materialized by a test execution bar that remains green.

Clean Tests

For TDD to be effective, a test must be clean, which is characterized by its readability. This is obtained by performing a simple, clear and dense a test as possible, IE making him say as many things as possible in a minimum of code. A unit test sould represent only one concept and contain only one assertion.

There are 5 rules that can easily be memorized using the acronym "FIRST":

Fast - A test must be fast to be executed often.
Independent - Tests must not depend on each other.
Repeatable - A test must be reproducible in any environment.
Self-Validating - A test must have a binary result (FAIL or SUCCESS) for a quick and easy conclusion.
Timely - A test must be written at the appropriate time, IE just before the production code it will validate.

Tools

For best practice, TDD must be coupled with good tools. An IDE like Eclipse with native JUnit support is essential. The use of plugins to facilitate he management of unit tests such as MoreUnit and Infinitest is strongly recommended. The latter automatically executes all unit tests at each code change, which reduces the feedback cycles that also lay the foundations for continuous unit tests. On the other hand, the use of code templates for unit tests is an important time saving in the repetitive TDD cycle. At the code level, for the generation of readable and flexible and business objects, the design pattern Builder is essential. Finally, a good mastery of keyboard shortcuts saves valuable time.

Sources: (click on them to see them)

TDD Concepts