Pruning and de-duplicating suites

How it works

Test suites grow faster than anyone reviews them. The model reads tests together with coverage data and run history and looks for redundancy: tests with near-identical steps and assertions, tests whose coverage is entirely contained in another's, tests that have never failed in years and assert only trivial things, tests that reference removed features or are permanently skipped. For each candidate it explains the reasoning and what would be lost by removing it. Mutation testing can give evidence that removing a group of tests doesn't reduce what the suite catches. Proposals go through normal code review; nothing is removed automatically.

When to use it

Suites that have become too slow or costly to run; inherited test code with no clear owner; after a product area is retired or rebuilt; and before migrating a suite to a new framework, so the dead weight isn't migrated with it.

Limitations

A test that never fails may be guarding against a rare but serious regression, and history can't distinguish that from a useless test. Two tests that look alike may cover different configurations or data. The model's sense of what a test is for comes from its name and code, which are often misleading in old suites.

What you still own

Every removal decision, and knowing which old tests exist because of a past incident.

Cite this