Designing Tests That Survive Refactorings
Half a day on why the test suite breaks every time someone refactors, and what to do instead.
- Format
- Half-Day Workshop
- Duration
- 4 hours
- Group size
- 12 to 25
- Level
- Intermediate
“My tests break every time I refactor.”
If someone on your team has said that this month, this is the half day for them.
They have written the tests. Coverage might even look respectable on the dashboard. And still, every refactoring turns green red, and nobody quite trusts the suite when it matters.
The problem usually isn’t too few tests. It’s tests coupled to how the code works instead of what it does. Tests that verify implementation. Tests that became a bill the team pays every sprint instead of a safety net.
This session pulls that apart. Not with a list of rules to apply, but by challenging the assumptions the suite was built on, and letting the team argue it out. Half a day, no laptops, a lot of talking.
Teams tend to leave this one with an opinion they didn’t have that morning, and a list of tests they now want to delete.
What your team leaves with.
Outcomes · 4- A definition of a real unit test the whole team agrees on
- Techniques for designing tests around behaviour rather than implementation
- A shared view of how domain-centric architecture makes a test pyramid possible
- An honest read on which of your current tests are earning their keep
How it runs.
4 hoursEffective testing strategies
A no-code session. Discussion, exercises and collaborative problem-solving aimed at the assumptions underneath the test suite rather than the syntax on top of it.
- What a real unit test is, and what it isn't
- Designing behaviour-focused tests that survive a refactoring
- How architecture decisions decide testing outcomes
- Building a test pyramid on domain-centric design
- Balancing confidence against maintenance cost
Who it's for.
No code, no laptops- Teams whose tests break on every refactoring
- Teams with high coverage and low confidence
- Anyone who cares about maintainability more than about the coverage number
- Experience writing tests
- No computer needed
Adapted to your team.
Before the dayWhat's above is the shape, not a script. We start with a 30-minute call about your codebase, your stack and what your team has already tried. The exercises get rebuilt around that, and anything that doesn't apply to you gets cut.
- The examples, moved into your domain
- The depth, tuned to the room
- The length, from 4 hours to what your calendar allows
Questions we get.
FAQ · 4Is this a hands-on coding workshop?
No. This one is deliberately no-code, and nobody needs a laptop. It runs on discussion, exercises and collaborative problem-solving, because the thing that needs to change is how the team decides what to test, not how they type it.
Our tests keep breaking when we refactor. Will this help?
That is the session. Your team will work out why tests break under refactoring, and how to design around behaviour instead of implementation detail so they stop.
We have high coverage but still lack confidence. Will this help?
Yes. The session goes after the coverage mindset directly, and looks at where confidence actually comes from.
Can it be run remotely?
Yes. It works on site or remote. No-code makes it one of the easier ones to run well over a call.
Who runs it.
In the roomGui Ferreira facilitates start to finish. He's been writing software since 2006 and is a Microsoft MVP. There's no junior trainer and no handover.
guiferreira.meThe other workshops.
Catalogue · 2Request this workshop.
10 questions, 3 optionalTell us about the team who'd be in the room. We read every one of these. If it's a good fit, we'll set up a 30-minute call and send a proposal within 48 hours of it. If it isn't, we'll say so.
