Test-driven development (TDD) involves writing unit tests before production code to reduce defects and debugging time. The three rules of TDD are: 1) write failing tests before production code, 2) only write enough test code to fail initially, and 3) only write enough production code to pass failing tests. TDD results in production code that is well-tested, easier to change over time, and protected from inadvertent errors through automated tests. An example bowling game scorekeeper demonstrates TDD in practice.

1. TEST DRIVEN DEVELOPMENT
At 10,000 feet
Let’s begin→

2. WHY TDD?
• We need a way to find defects earlier on in the development cycle..

3. TDD REDUCES DEBUG TIME

4. TESTS = CODE EXAMPLES

5. NO TDD = NO VELOCITY
• The more complex our code becomes, the longer it takes to make
changes or add new features.
Hard to change
Complexity
Time 
Easy to change

6. TDD PROTECTS US FROM OURSELVES
• Automated tests remind us when we inadvertently screw up part of
the code. No matter how significant.

7. TDD EMPOWERS YOU

8. THE THREE RULES OF TDD

9. RULE # 1
• You are not allowed to write any
production code unless it is to
make failing unit tests pass.

10. RULE #2
• You are not allowed to write any
more of a unit test than is
sufficient to fail; and compilation
failures are failures.

11. RULE #3
• You are not allowed to write any
more production code than is
sufficient to pass the one failing
test.

12. TDD IN PRACTICE

13. SAY WHAT?

14. Let’s
see
some
code

15. The Bowling Game
1 4 4 5 6 5 0 1 7 6 2 6
5 14 29 49 60 61 77 97 117 133

16. • Test code is just as important
as production code and should
be shown the same level of
respect and professionalism.

17. THANK YOU!
Any Questions?