Test Driven Development (TDD) is a software development technique that forces programmers to develop in baby steps. Because it also enforces your code to be testable it helps you make better design decissions and thereby promotes a simpler and better design of the code base.

The TDD mantra: Red - Green - Refactor:

• Red: write a test (it fails of course)
• Green: write the least amount of code (the simplest thing that works) to make the test pass.
• Refactor: rearrange your code to eliminate duplication and allow patterns to evolve.

Or in other words: Bob Martin's three rules of TDD:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

There is plenty of research (list by Bob Martin, list by John Smart) about how TDD affects projects. This 2008 case Study of TDD at IBM and Microsoft shows that TDDers enjoy a defect density reduction ranging from 30% to 90% (as measured by defect tracking tools) and a productivity cost of between 15% and 35% (the subjective opinion of the managers).

Related articles:

• Problems and Solutions when adopting TDD

• Effective exercises for teaching TDD

• Teaching and learning design using TDD (#GOOSgaggle)

• Mindmap on teaching/learning TDD
• Presentation: TDD from Hell