Don't tear down the fence: the test you're tempted to delete
Two hours, live online, with a short break. A grounded look at Chesterton's Fence in software testing — why the test that looks pointless is so often the one you can least afford to delete, and how to tell the difference before you do.
- Chesterton's Fence, applied to test suites — why "this test is useless" is the most expensive sentence in a codebase.
- How to read the history of a flaky, slow or confusing test before you reach for delete.
- A practical rule for when removing a check is genuinely safe — and when it's a production incident waiting to happen.
The follow-up to the WeAreDevelopers talk — live, and going further.
There's an old principle: don't tear down a fence until you know why it was put up. It was written about reform, but it might as well have been written about software testing. Every test suite has a fence somebody wants to remove — the slow check, the flaky assertion, the rule nobody remembers writing. This free, two-hour webinar takes that idea seriously and applies it where it bites hardest: the tests, checks and guardrails we're tempted to delete because we no longer understand them.
This is the live follow-up to the WeAreDevelopers talk "Don't Tear Down the Fence." The talk made the argument; this session goes further — into how you actually investigate a fence before you remove it. We look at the difference between a test that's genuinely dead and a test that just *looks* dead, the cost of getting that call wrong, and the questions worth asking before any check leaves the suite.
No hand-waving about "best practice." Just an honest look at why so much of what protects a product is invisible until it's gone — and a method for deciding what's safe to cut, from someone who's watched a few fences come down the hard way.
The questions the session is built around.
These are the questions this session works through — posed and answered live, with room for your own at the end.
- 01
Where does Chesterton's Fence come from, and why does it map so cleanly onto test suites?
- 02
What's the real difference between a test that's dead and a test that only looks dead?
- 03
Why is "this test is useless" so often the most expensive sentence in a codebase?
- 04
How do you investigate why a check exists when the person who wrote it is long gone?
- 05
Flaky, slow, confusing — which of these actually justify deletion, and which are just signals to fix?
- 06
What does it cost when you remove the wrong fence, and how late do you usually find out?
- 07
Is there a safe rule for retiring a test — and what has to be true before you apply it?
- 08
How do you build a suite where the fences explain themselves, so the next person doesn't have to guess?
Save your seat — before someone else does.
You'll get the Zoom link the day before the session, and a calendar invite straight away.
The person who'll also answer the email.
Imola
Software-testing practitioner and quality advocate with fifteen years in the field — across product teams, agencies and in-house QA orgs. Has hired testers, been hired as one, and watched the job market change shape three or four times already.
Today Imola runs Pearly Quality from Hungary: the workshops, the monthly letter, the podcast, and the occasional honest conversation about where this profession is actually going.