Which automated tests can you delete without losing important coverage?
Deleting automated tests does not have to weaken coverage. A test that no longer verifies valid behaviour, merely duplicates other evidence, or has lost the team’s trust can slow the suite and obscure more important results. A safe decision cannot be based only on a test’s age or failure frequency; it needs a risk map and evidence of what remains covered after removal.
Why tests keep accumulating
Every new test has a clear creation point but rarely a scheduled review date. A feature changes, the same rule is verified at three layers, and a temporary scenario stays in regression for years. Together, these tests extend execution time, complicate data preparation and create more results to evaluate.
When a suite becomes unstable, deleting its most frequent failures is tempting. That is a dangerous shortcut. An unstable result may indicate a defect in the test, an environment problem, or a real concurrency defect in the application. First measure which tests are flaky and why; only then decide what they are worth.
Distinguish four reasons to act
Not every candidate belongs in the bin. Classify it by reason first:
- An obsolete test verifies a feature or rule that no longer exists. Confirm this with the product owner and current requirements; an old button label is not sufficient evidence.
- A redundant test provides the same evidence as another test against the same risk. Compare data, roles and conditions too. Two similar sequences may verify different permissions.
- An untrustworthy test has no meaningful assertion, remains skipped indefinitely, or passes despite incorrect behaviour. If it protects an important risk, it should be repaired or replaced rather than deleted.
- A disproportionately expensive test takes too long or needs too much maintenance for the information it provides. It can often move to a lower layer instead of disappearing entirely.
Age alone proves nothing. An old test for a critical calculation may still be valuable; a new test without a relevant assertion may not be.
Map coverage before deleting anything
For every candidate, record the risk, expected outcome, and other tests that provide the same or complementary evidence. A table with “risk – scenario – layer – owner – last useful finding” is enough to begin.
Then ask three questions:
- If this test disappears, which other test will reveal the same incorrect behaviour? A similar name is not enough; compare the actual assertions.
- Is the current layer proportionate? Input combinations may be covered more cheaply by unit or API tests, while one end-to-end scenario retains evidence that the journey works as a whole.
- Does the risk still matter? The team may consciously accept a low-impact risk, just as it decides what is not worth automating.
If the map exposes a gap, create replacement coverage or explicitly accept the risk before removing the original scenario.
Choose keep, repair, replace or delete
| Decision | When it is appropriate |
|---|---|
| Keep | The test protects a valid, material risk and provides unique, trustworthy evidence. |
| Repair | The risk matters, but the test implementation is unstable or difficult to understand. |
| Replace | The same evidence can be obtained more precisely, quickly, or at a more suitable layer. |
| Delete | The expectation is obsolete, the evidence is demonstrably redundant, or the team has consciously decided that the risk no longer needs coverage. |
A larger problem may require a decision to repair or rewrite the suite. Individual tests must still be judged by value; a mechanical rewrite carries old baggage into new code.
Remove tests in small, verifiable groups
Mark candidates with a reason and owner first. When uncertain, exclude them from routine runs for a limited period, monitor the related risk and set a date for the final decision. Permanent quarantine merely moves the problem out of the report.
Once approved, remove data, configuration and documentation used solely by the test. Do not leave commented-out code “just in case”; version control provides recoverable history. Compare run time, the number of unclear failures, and critical-journey coverage after the change. If the suite starts growing without rules again, address why test suites become unreliable.
What you gain
A smaller suite provides faster, clearer feedback. The team spends maintenance effort on tests that protect real risks and can explain why every removed scenario was replaced or no longer needed. Deletion becomes a controlled decision instead of tidying by instinct.
Next step
Start with the ten slowest, most frequently skipped, or most duplicated tests. Record the risk and replacement evidence for each before changing the code. Only then classify the candidates as tests to keep, repair, replace, or safely remove.