Gone are the days are prescriptive specs and manual tests. But as you adopt modern development, you may find yourself with ineffective unit tests instead. Listen to 14 minutes of Arlo describing what drives how unit tests get written, and what we need to do in order to achieve the incredible results TDD can give us.
Video spoiler alert: you simply can’t do effective unit testing on messy code. It has to be refactored first.
These are some of the more common questions we get.
How can we write unit tests that will be useful in the long term?
How do we avoid slow brittle tests?
My code is not unit testable, but I can’t fix that until it is unit tested. How do I break free without a rewrite?Soooo many people.
Tier 1: Getting the Foundations
Invest 6 weeks of Code by Refactoring Foundations to fundamentally change how developers refactor so that they execute unit tests successfully.
- Start Refactoring Safely (2 virtual weeks)
- Naming as a Process (2 virtual weeks)
- Know When to Stop (2 virtual weeks)
Tier 2: Addressing Specific Unit Testing Challenges
Once the foundations are adopted, invest 4 weeks at a time for an advanced topic depending on what problem the team is facing. As teams usually face different issues, it is common that each team takes a different advanced workshop.
Example Advanced Workshop Options
Problem: How do I test parallelism, UI, databases, and networks?
Workshop Series: Test Challenging Dependencies (12 virtual weeks)
Workshop Result: Learn how to identify and separate the code’s behaviour and execution context so that each can be tested independently.
Problem: How do I test intertwined code that was not designed to be tested?
Workshop Series: Test Untestable Code (14 weeks)
Workshop Results: Learn how to incrementally separate and test a piece from the intertwined code ball until everything is tested.
Problem: How do I test behaviours that emerge from the integration between components?
Workshop Series: Test Integration Behaviours (14 virtual weeks)
Workshop Results: Learn how to improve a cohesive design so that every behaviour comes from one component and can be tested.