The document discusses test-driven development (TDD) principles and techniques. It outlines an approach to TDD involving writing one failing test at a time, making it pass with just enough code, and refactoring within time limits. Key aspects include pair programming, following the four elements of simple design, and taking "baby steps" with a timer to focus on small, frequent changes.

1. TDD as if the baby meant it

2. Agenda
Me
The rulez
The problem
not the same as the first point on the agenda!
The experience
The reflection
More fun

3. The rulez

4. Pair programming

5. Four elements of simple design
1. Passes its tests
2. Minimizes duplication (of concepts)
3. Maximizes clarity (naming, intent)
4. Has fewer elements (as small as possible)

6. TDD as if you meant it
Write one failing test
Make it pass by writing implementation code in the test method
When duplication is spotted extract implementation from tests to:
a new method in the test class
an existing method in the test class
When more methods belong together extract them into a new class
Refactor as required

7. Taking baby steps
Setup source control repository.
Setup a timer for 2 minutes interval when you start.
Write exactly one test
If the timer rings and the test is red then revert and start over.
If the test is green before timer rings then commit.
Restart timer (no discussions in between timers)
Refactor
If the timer rings and the refactoring is not complete then revert and
start over.
If the refactoring is complete before the timer rings then commit.
Restart the timer (no discussions in between timers)

8. Let’s dive in

10. Let’s dive in again

11. Let’s reflect