Repair the test suite or rebuild it from scratch?
When a test suite fails frequently and the team does not understand it, a complete rewrite can seem like the simplest solution. In practice, that may discard valid scenarios and valuable product knowledge. At the same time, repairing a foundation built on unsupported dependencies or testing processes that no longer exist makes little sense.
Why an all-or-nothing decision fails
A single suite often contains strong critical scenarios, duplicate checks, fragile infrastructure and obsolete tests side by side. One decision for the entire repository therefore tends to cause either an unnecessary rewrite or endless repairs.
Tests also preserve the team’s experience: edge cases, permissions and combinations that have caused problems before. This knowledge does not automatically survive a rewrite, especially when the original author is no longer available.
Four possible decisions
Repair
Repair is appropriate when the scenario still provides value, the tool is maintained and the problem has a local cause. The issue may be a selector, waiting logic, test data or environment configuration. After the repair, the same measurement should confirm that instability has fallen.
Redesign
The test may have the right objective while its steps are duplicated or too tightly coupled to the interface. In that case, preserve the scenario and its assertions but improve the architecture, data setup or separation of responsibilities. Redesign can proceed incrementally so the working part of the suite remains available.
Migrate
Migration makes sense when the tool, language or infrastructure no longer has a sustainable future within the team. It is not a mechanical line-by-line translation. Valid scenarios and expectations are retained while the technical foundation is rebuilt. Our test migration service covers this option.
Retire
A test can be removed if it checks a discontinued feature, exactly duplicates another check, or has no clear and useful outcome. Someone who knows the product should confirm the decision, and the reason should remain traceable.
How to assess the suite
First, run it in a known, reproducibly prepared environment and measure its instability. Then assess every scenario against:
- its importance to the customer or a key process;
- the validity of its expected outcome;
- the frequency and cause of failures;
- the state of the tool and its dependencies;
- maintenance effort and the skills available within the team;
- the cost of repair compared with migration.
The result does not have to be one answer. A plan may combine several categories: repair or migrate some critical tests, redesign the architecture incrementally, and retire obsolete checks.
What to watch out for
A new framework will not by itself remove unsuitable scenarios, shared data or missing ownership. If the same design mistakes are copied during migration, the new suite will develop the same problems over time. The cause—not merely the number of failures—must therefore be understood before a decision is made.
What you gain
- Valid scenarios and product knowledge are preserved.
- Spending is directed towards repairs with a clear benefit instead of a blanket rewrite.
- A risky technical foundation can be replaced incrementally.
- The team receives a clear plan for what will happen to each part of the suite.
Next step
Choose a representative part of the suite and label each test with its purpose, status and most frequent reason for failure. If you need an independent assessment, contact us. We will prepare a decision overview—repair, redesign, migrate or retire—together with an order for the next steps.