Yes, delete a test when a faster, lower level test already covers the same behavior and the higher test adds nothing else. Keep any test that guards a security rule you cannot prove is covered elsewhere. The goal is a suite people trust and run, not the biggest suite.
Why pruning matters
Slow, flaky suites get skipped, retried until green, or ignored. A security test that nobody trusts is worse than none, because it creates false comfort. Martin Fowler's test pyramid article lists the cost of duplication as time to write, read, maintain and run, and advises pushing each test as far down the pyramid as possible.
It also says plainly: beware the sunk cost fallacy and hit the delete key. The effort already spent on a test is not a reason to keep it.
The decision, step by step
For each candidate test, ask:
- What behavior does it check? State it in one sentence.
- Is that behavior covered by a lower level test? If a unit test checks the same rule in milliseconds, the end to end version is likely redundant.
- Does it check anything the lower test cannot? Wiring, configuration, real network behavior and cross service flows are things only higher tests see.
- Is it a security rule? If yes, move to the next section before deleting.
- Does it flake? A flaky test that duplicates coverage is the easiest deletion.
If a higher test fails and no lower test does, Fowler's advice runs the other way: add a lower level test to isolate the problem. So pruning and adding go together.
Protecting security checks
Do not delete a security test because it looks old. Before removing one:
- Find which test covers the rule now. If you cannot name it, keep the test.
- Check why it was added. A commit message or ticket often shows it came from a real bug.
- Move it down the pyramid rather than deleting, where possible. Rewrite the end to end check as a unit test on the policy function.
- Keep a short list of rules that must always be tested, such as authorization on each sensitive endpoint, and review the list when you prune.
What about duplication that helps?
The same article says readability often outweighs avoiding repetition in tests, and suggests the rule of three before refactoring test code. Some repetition is fine if it makes a test easier to read. The target is duplicated coverage, not repeated lines.
A pruning session
- List the slowest twenty tests.
- For each, apply the questions above.
- Delete or demote what you can in small pull requests, each with a note explaining the coverage that remains.
- Run the suite and record the new duration.
- Repeat quarterly.
Test code deserves review
Fowler states that test code is as important as production code. Review deletions as carefully as additions, and have a second person confirm that a security test being removed is truly covered.
Safeguard adds checks the test suite cannot: dependency and SBOM scanning, and zero day discovery for components you use. The free scan is at gold.safeguard.sh/scan.
Quick check
How do I know a test is redundant?
If a faster test checks the same behavior and the slow one checks nothing additional, such as wiring or real integrations, it is redundant.
Is coverage percentage a good guide?
Not on its own. Coverage shows lines executed, not whether the right behavior was checked. Use it as a hint, not a target.
Sources
Last reviewed: 19 October 2026.
