When you’re working in TDD you’d like your cycles to be short and fairly regular. Let’s look at that today.
- 5 min connect: 3 things about TDD plus one
- 5 min concept: TDD cycle
- 35 min concrete: do some TDD
- 10 min reflect: Correlate test list with TDD cycles
Connect: 3 things about TDD plus one
Ask participants: What are three things you already know about TDD? Tell them to the person sitting next to you. Bonus: also tell them one thing you want to learn about TDD.
Concept: TDD Cycle
Bring up an example cyber-dojo screenshot with some traffic lights. Show a TDD cycle. Explain you would like them to be short and fairly regular.
Concrete: Do some TDD cycles
Pick an exercise, one that is not too complicated and you can fit several TDD cycles into 35 minutes. For example Closest to Zero. Ask them to work on it using TDD.
If you’ve previously done a ‘test list’ learning hour on this kata you could remind them of it and distribute the list you made that time. Otherwise, remind them to make their own test list.
Reflect: TDD cycles and test list
Review the code and TDD cycles. A tool like cyber-dojo makes test cycles visible, but you can also use the local history in your IDE, or git history.
- Were the cycles even in length, did you get a good TDD rhythm going?
- Did you have one TDD cycle per test on your list?
- Did you add or remove tests from your list during development?
- What factors lead to successful TDD cycles?