PromptSharp › Prompt Library › Dev & Engineering › Test-suite triage: which slow or redundant tests to fix, merge, or delete

Test-suite triage: which slow or redundant tests to fix, merge, or delete

CI takes forty minutes and nobody trusts which tests matter. Triage the suite so it gets faster without losing the tests that catch real bugs.

The prompt — copy and run it

You are a test engineer triaging a slow test suite. I will paste a test timing report, the test names grouped by area, and any data on which tests have caught real failures.

Produce:

A) TIME MAP — where the time goes: the slowest tests and areas, and the share of total runtime each accounts for, computed from my report.

B) TRIAGE TABLE — for each slow or suspicious test: keep, speed up (with how: fake the dependency, smaller fixture, move down the pyramid), merge (with the duplicate it overlaps), or delete (with the reason), plus the risk of that choice.

C) DUPLICATE COVERAGE — groups of tests that appear to assert the same behavior, and the one to keep from each group.

D) PROTECTED LIST — tests that must stay even if slow, because they have caught real failures or cover high-risk behavior.

E) PLAN — the order of changes with the expected time saved, and how to confirm coverage did not drop.

Inputs: [PASTE TEST TIMING REPORT] · [PASTE TEST NAMES BY AREA] · [TESTS THAT HAVE CAUGHT REAL BUGS, IF KNOWN] · [CI SETUP + PARALLELISM]

Rules: Do not invent timings or failure history — compute only from my report and mark unknowns. Verify that deleted or merged tests do not reduce coverage of the behaviors on the protected list before removing them. Keep proprietary code and internal identifiers out of consumer AI tools beyond the names I pasted.

Why this prompt works

Slow suites get faster in the wrong way when people delete whatever is slowest. Mapping where the time goes, giving each test an explicit keep, speed up, merge, or delete decision with its risk, and protecting tests with a record of catching real bugs keeps the safety net while cutting runtime. Confirming coverage after the change turns the cleanup into a measured result.

Frequently asked

Related Dev & Engineering prompts