TDD Patterns by Gil Zilberfeld
You’re in that zen mode, ready to go into designing code with tests. You know all about emerging design, your mind is empty, and off you go.
What scenario do you pick to start with? How do you translate not-so-specific requirements into example tests? What happens when you run out of examples? Do you ever get back to the first requirement, or skip between tests as more bright ideas flash into your mind?
Over the years, I’ve discovered patterns I use in TDD. From improving names, mutating tests to create more examples, picking scenarios and differentiating them from their siblings. I’ve noticed others doing them too.
In this session, I’m going to tell you about my experience, and what methods are effective for me. I’m going to show examples, explain the thought process, and tricks that help me along the way.
Different sets of patterns of how people do TDD:
- Social (alone, pairing, understanding)
- Decison making (ideation, solutions, where to stop)
- Emergent design (constraints, design practices)
- Techniques ( Naming, happy/easy path, algorithms)
|Constraints and Class Arrangement||
Projector and screen
Agile Testing Days 2014
|Last Updated||04 Jan 18:40|