Test-Driven Development and Design Patterns

Test-Driven Development and Design Patterns Last month, in my conversation with Scott Bain on Impediments to TDD, I wanted to explore how he was incorporating TDD and Design Patterns, two areas of particular expertise for Scott. That is the topic of today's conversation. Scott has been thinking deeply about patterns for many years and his perspective on TDD and patterns are based on the special insights he has developed - insights that are covered in the Design Patterns Explained course he teaches. What he says goes well beyond the normal way in which patterns are described. As you will hear, we came up with some delightful surprises during our talk together Embracing Change  In this conversation, we cover how TDD is like design patterns. Both deal with change, something that is always with us in product development. Our natural tendency is to want to resist change because change usually causes us pain. TDD and patterns both help remove the "sting" of change. But beyond that, it becomes something that we can even embrace as a good thing, something that can work to our advantage. Working together, TDD and patterns form a virtuous feedback loop, each reinforcing the other. This is the sweet spot for patterns and TDD. Evaluating Designs and Testing Strategies  Going deeper, Scott explores how testability becomes an essential factor in evaluating design alternatives. Like Occam's Razor, when you have competing design alternatives, choose the one that is more testable. This is especially important when you are working from a TDD perspective. Well, if you are working from a patterns perspective, you will naturally have highly testable designs: highly cohesive, minimally coupled, focused on just one thing. That is just what patterns do. Take this deeper. Each pattern is focused on resolving certain forces; it has certain structures and characteristics that are more important. By focusing on testing these characteristics, you have the head start on what would be the most effective testing strategy to use. And this is a cool insight that could be very powerful for our industry. What if testing became part of how we talk about patterns, became yet another essential characteristic of the pattern? Would that free us up from reinventing testing strategies for what are commonly occurring situations? Wouldn't this further our knowledge transfer about what is an essential need? Wouldn't it give us a good language to use? Even more, testing approaches, such as mock objects, dependency injection, shunts, can be expressed as patterns. "Testing patterns" become a whole new class of patterns that professional software developers can use, discuss, refine. To this end, Scott has entered the first testing pattern, a Mock Object Pattern, into the Pattern Repository at https://www.netobjectives.com/PatternRepository/ and invites your insights, comments, and additions. How to Learn this Way of Thinking with Patterns and Testing This is affecting the way Scott teaches Design Patterns Explained and Test-Driven Development, but not in the way I would have thought. DPE is very focused on helping people understand what patterns are. There is usually a lot of unlearning/re-learning that has to take place. This means that the course is almost entirely consumed by the pattern-specific training. The same is true for the TDD course. The Emergent Design book that is out now and the course that will be coming will serve as the bridge between them, talking about how they interact, how this allows for evolutionary design. If you want to get good at this, is it better to start with TDD or with DPE, given that you really should know both? In Scott's opinion, it is best to start with DPE because it gives you the essential thinking framework that then equips you for the practical TDD instruction. What seems to work best is to take them with just a one week gap in between. In his experience, this makes for a solid performer on the back end. Scott is an excellent speaker