# When is it safe to delete an old regression test? > Delete obsolete regression tests only after proving the protected behavior is retired or covered elsewhere without losing a unique boundary check. Canonical URL: https://www.devobs.io/articles/qa-delete-obsolete-regression-tests/ By: Sofia Reyes Published: 2023-06-14T11:02:11.201Z Updated: 2026-09-06T08:31:04.426Z Section: Architecture Delete an old regression test when you can show three things: the behavior it protected is no longer a current obligation, or a newer test proves that same obligation, and removing the old case does not erase unique boundary evidence. Age is not a reason. A bug ID is not a reason either. If the test still protects user-visible behavior, keep it. If it only mirrors implementation, rewrite or remove it. ## What obligation does the test still prove? Start by translating the old regression into a present-tense statement about the system: what user, caller, or dependent component relies on this behavior today? That is the real unit of decision. This matters because tests should primarily protect behavior, not internal structure. As the [Google Testing Blog on testing behavior, not implementation](https://testing.googleblog.com/2013/08/testing-on-toilet-test-behavior-not.html) puts it, tests should focus on the public API and should not need to change when only implementation changes. If your regression fails every refactor while proving nothing user-visible, it is probably not preserving an obligation. It is just tracking code shape. The same source also makes the practical maintenance point: tests independent of implementation are easier to maintain and understand. That is a good deletion signal for brittle regressions that no longer express an externally meaningful promise. ## Has the protected behavior been removed or replaced? A regression test can be safely deleted when the product obligation itself disappeared on purpose. Examples: the feature was removed, an old parser no longer accepts that format by contract, or an endpoint was retired and callers were migrated. What is not enough is a preflight check like, "the code path seems gone." Identify the enforced ordering boundary instead: where is the new contract defined and how is the old one prevented? For example, if validation now rejects the legacy input before business logic runs, and that validation is itself covered by current tests, the old downstream regression may be obsolete. Also delete or rewrite tests that are only change detectors. The [Google Testing Blog on change-detector tests](https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html) describes these as tests that break on any production change "without verifying correct behavior." Those tests add maintenance cost without preserving confidence. ## Does another test really cover the same evidence? Duplicate setup is not duplicate coverage. Two tests may build the same fixture and still prove different obligations. Before deleting, compare assertions and boundaries, not helper code. Use this checklist: - Name the obligation in one sentence. - Identify the exact input boundary or failure mode the old test covers. - Point to the replacement test that proves the same observable result. - Check whether the replacement includes the same edge condition, not just the happy path. - Delete only after the replacement test is merged and passing. Worked example: suppose you kept a regression for "empty coupon code must not crash checkout and should return total unchanged." Later, checkout input validation rejects empty codes at the API boundary with a 400 response. If current API tests assert that empty coupon codes are rejected, then the old service-layer regression no longer protects a live obligation. Delete it. But if the only remaining test checks a valid coupon path, keep the old regression or replace it with a boundary-focused validation test. ## Should a historical bug ID keep a test forever? No. The reason to keep a test is a current obligation, not memorial value. Keep the bug link in the commit or test history, but let present behavior decide whether the test stays. ## Does duplicated setup imply duplicated coverage? No. Shared factories, mocks, or fixtures only show similar construction. Coverage is duplicated only when the observable contract and boundary condition are both already proved elsewhere. Your next step: pick one suspect regression test and write its protected obligation in a single sentence. If you cannot name a current obligation or unique boundary, you have a strong case to delete or replace it. Reviewed: 2026-09-05 ## Source references - -