Designing Tests That Survive Refactorings
Half a day, no laptop, working out why your tests go red every time you move code that still works, and how to design the ones that don't.
What you'll achieve:
- A definition of a unit test you can defend in a code review
- Tests written against behaviour, so moving code stops breaking them
- The link between the architecture you picked and the test pyramid you ended up with
- A shortlist of tests you can delete tomorrow without losing any confidence
Prerequisites:
- You have written tests before, in any language
- Your suite goes red when you refactor, and you want to know why
- No laptop. Bring a pen.
You rename a class. Forty tests go red. Not one of them was testing the rename.
Nothing is broken. The behaviour is identical to what it was five minutes ago. But the suite doesn't know that, because it was never watching the behaviour. It was watching the shape of the code.
A suite like that is not a safety net. It's a second copy of your codebase, written in a more awkward language, that you now have to keep in sync by hand. Every refactor costs twice. So you stop refactoring, and the design quietly rots around the tests that were supposed to protect it.
The fix isn't more tests. It's a different kind of test, and an architecture that makes that kind of test possible in the first place. Those two things are the same problem, which is why most advice about testing doesn't land. You can't write a good unit test against a design that won't let you.
What happens in the room
Four hours, no computer, no slides to sit behind. I bring the problems and you bring the codebase you actually work in. We define what a unit test is, out loud, until the room agrees. Then we take that definition apart on real examples and see what it costs.
It's a conversation, not a lecture. You will be asked what you think and you will be disagreed with.
Is this for you?
If you've written tests before and you're tired of them breaking on work that changed nothing, yes. It helps if you've been through at least one refactor you abandoned because the suite made it too expensive.
If you're looking for framework tips or an introduction to xUnit, this isn't it. Nothing here is about tooling.
Bring one thing
Come with a test from your own suite that broke last week for no good reason. We'll work out together why it broke, and what it should have looked like instead.
Curriculum
One session, four hours, run as a conversation. I bring the problems, you bring the codebase you actually work in, and we argue about it in the open.
Effective testing strategies
We start by disagreeing about what a unit test is, because most teams have never written the definition down. Everything else follows from where that line lands.
Key Topics:
- Where the line sits between a unit test and everything else
- Writing against behaviour when the behaviour is buried in implementation
- Why your architecture decided your test pyramid before you wrote a test
- Reading a suite for which tests carry weight and which carry cost
- Deciding what confidence is worth, and what you will pay to keep it
Catch it in public
When this runs in public it runs at a conference, and the conference sells the seat. Registration goes to them, not to me.
No public dates for Designing Tests That Survive Refactorings
Nothing on the public calendar for this half-day workshop right now. Black Lab Studios books private sessions all year.
Frequently Asked Questions
Want this for your team?
Private sessions run on-site or remote, against the codebase your team actually works in. Black Lab Studios, the company I founded, handles the scoping and the contract. I run the room.