Coding Dojo with Emily Bache at XP2011

I’m at XP2011 in Madrid, enjoying a coding dojo session with Emily Bache. We’re tackling a Minesweeper kata, and as long as it’s not yet my turn to code, I’ll summarise her introduction to TDD which I liked a lot.
(Thanks to Markus Gärtner for the inspiration)
Emily started with a story of a developer who joined her team and impressed her big time with his gear: a Mac with a stylish mouse… When later she started integrating his code with her own, she realised the quality of his code did not live up to her expectations. It turned out he didn’t run the code at all… The lesson learned from this story: don’t trust a smart mouse;-)
In contrast to Uncle Bob’s 3 steps of the TDD cycle (red, green, refactor) Emily teaches a four-phase approach. This includes a setup stage where you quickly think through what you’re going to do and come up with a rough plan.

TDD States and Moves

1. Starting

Analyse the problem and come up with a rough path. Then draft a list of test cases. Create one guiding (acceptance) test to constantly remind you where you’re heading.
Move on when you have a goal.

2. Get to Red

Declare a name for the new test. Use the arrange-act-assert pattern to write the test code.
Move on when the test is red.

3. Get to Green

Implement the simplest solution. Fake it if that works;-) If it doesn’t, start over…
Move on when all tests execute and are green.

4. Refactor

Remove all fakes. Remove code smells. Build no new functionality!
Move on when the code is clean, all tests still execute and all are green.

The top reason for doing TDD I took away from Emily’s session is that you get Feedback on the design of your code.

She quoted David Tchepak who said, TDD constrains the problem space we are looking at, as well as provides feedback on how well we are addressing this problem.

After this introduction, we started the actual kata, which was insightful and good fun…

Thanks, Emily, for a great session starting an amazing conference!.