A slow suite does not always need a rewrite.
On one project, the tests themselves were not the main problem. CI ran them in a single line. Every pull request waited on the full 12-minute path.
I split the compatible groups across a matrix build. The total run time dropped to 6 minutes, and developers got feedback while the change still felt current.
That kind of change does not make weak tests strong. It makes useful tests arrive sooner.
Project note
Problem: A 12-minute test run slowed feedback on every pull request.
Action: I split the run across a CI matrix so compatible test groups could execute in parallel.
Result: Runtime dropped from 12 minutes to 6 minutes.
Lesson: Before rewriting tests, check whether CI runs them in the slowest possible shape.
Why it matters
Slow CI changes how engineers behave. They batch changes, context-switch away from failures, or treat CI as a late release gate.
Faster feedback can improve trust without touching the product code or rewriting the suite.
What teams should check
Use these checks when a release depends on similar behavior.
- Which test groups can run in parallel?
- Do tests share state that blocks parallel jobs?
- Which suites should gate pull requests?
- Which suites can run later or on a schedule?
- Do reports make parallel failures easy to trace?