Abstract: "I can't test this code because the design is awful. I can't refactor because I don't have tests. Yet it keeps having (and breeding) bugs. Now what?"
--- Everyone, everywhere
I've talked in the past about how this apparent catch-22 is resolved by a better understanding of the word "refactoring" --- that using a specific set of techniques allows defect detection and prevention even in untested --- or untestable --- code. Now I'm going to show you those techniques by applying them to some gnarly code.
This session is 75% live-coding, 25% talking. Most of the talking will be me asking you questions. So come if you want to think, want to get your hands dirty, and want to see specifics that you can try to apply immediately in your own code.
Agenda:
- Microtesting: understanding what the code does and deriving a spec.
- Resolve microtesting blocker: mechanically spot CQRS violations; resolve them via extract method + make method static.
- Resolve microtesting blocker: mechanically spot multiple responsibilities in a class; resolve them via extract method + make method static + introduce parameter object.
- Safeguarding: preventing bugs by eliminating hazards.
- Remove hazard: primitive obsession leads to inconsistent computation; resolve it via introduce parameter object + extract method + move method.
Learning Outcomes: - See a new way to test, with best features of both a unit test and an acceptance test.
- Observe that testing this way induces design pressure, and use that to guide your design.
- Spot and address the 2 most-common design obstacles to testing.
- Understand that defects are not spontaneous; they can be prevented by addressing hazards.
- Spot and address the #2 bug-creation hazard (#1 is naming, and that is already well-addressed in other work).
- Pick which habits to take home and learn by applying on your code.
