The most common mistake in adopting TDD is failing to let tests and testability actually drive design. Instead, the practitioner creates a design, then devises a clever, complex, often expensive, scheme to actually test that the design works. In true TDD, tests and testability force a variety of design moves. In this session, we'll explore some of the most basic ways we do this. We will cover several simple changes we can make in our detailed designs that will make microtesting easier and faster. In each case, we'll consider live code that illustrates the choices, the technique for moving between them, and the larger pattern represented by the specific case.
- Method Chaining -- Instead of using an awkward collaborator directly, provide two methods, one taking the awkward, one taking an easy, the former transferring to the latter
- Container Wrapping -- The collection systems of various libraries offer generalized and very rich container capabilities, but they come with two costs: over-broad API's aren't "fit to purpose", and testing using them can create problems of non-testability. Wrap containers quickly.
- Framework Dodging -- Frameworks are invaluable, but often highly intrusive, bringing severe testing limitations with them. Framework dodging is writing code that draws a clear line between "our" code, "their" code, and easy "dodge" code. We test our own code without using the framework at all.
- Supply-Supplier Swapping -- Sometimes a Supplier is more awkward than the Supply, somes vice-versa. Know the difference and how to swap between them.
- Party Hosting -- TDD leans towards networks of very simple collaborating objects. Who puts it all together? Learn to localize assemblies in the party host.
- Prototype Tweaking -- Got a gigantic data object? Don't instantiate it directly for tests. Give yourself a Prototype+Builder object that sets things up for you, emphasizing just the differences. Get far faster and less error-prone tests than manual dataset construction.
In TDD, we don't just make a design and then test it. We use the requirement of ready testability to constrain and expand our design as we go. Tests and testability literally drive the design. Learn these common patterns and skip past the hardest & slowest part of mastering TDD. Learning Outcomes:
- Attendees will learn the patterns in live code, seeing and feeling their results. In each case, we'll expand the simple code changes into a larger pattern of related changes.