32 / 57 · 26 Testing Like a Senior · Testability and Test Curation← prev⊞ allnext →☰ Read as one page
8.3Killing Bad Tests
Anti-Pattern: The test suite only grows. Nobody deletes tests because "what if we miss a bug?" The suite becomes slower, flakier, and harder to maintain. New tests are added; dead tests accumulate.
Pattern: Regular test suite curation. Tests have a cost (maintenance, execution time, cognitive load) and a value (bugs caught, confidence provided). Delete tests where the cost exceeds the value.
Categories of Tests to Delete
| Category | Description | Example |
|---|---|---|
| Tautological | Tests that cannot fail, or test the framework/language itself | expect(true).toBe(true), mocking a function and asserting the mock was called |
| Duplicate coverage | Multiple tests covering the same path with no additional value | Three tests that all verify successful login with valid credentials |
| Implementation-detail | Tests that break when code is refactored without changing behavior | Asserting on internal method calls, private state, or CSS class names |
| Permanently skipped | Tests marked @skip or @ignore for months with no plan to fix |
Any test that has been skipped for more than two sprints |
Cost-Value Analysis
For each test (or test category), ask:
- How often does it catch real bugs? (value)
- How often does it fail due to flakiness or environment issues? (noise cost)
- How long does it take to run? (time cost)
- How much effort does it require to maintain? (maintenance cost)
If a test has not caught a real bug in six months, runs for 30 seconds, and breaks every other sprint due to environmental issues — delete it.