Every test suite eventually reaches the same uncomfortable size: hundreds of tests, a run time measured in tens of minutes, and a growing sense that most of it exists out of habit rather than necessity. Nobody wants to be the one who deletes a test that turns out to matter, so the suite just keeps growing, and CI keeps getting slower.
Testing theatre: suites nobody trusts enough to prune
The signs are familiar. Developers skip the full suite locally because it takes too long, running only a subset and trusting CI to catch the rest. CI itself creeps from five minutes to fifteen to forty-five, and a chunk of that time is quietly wasted re-running tests that were never going to fail. Nobody can point to a specific test and say with confidence “this one caught a real bug last quarter” or “this one has never once failed for a legitimate reason.”
That’s testing theatre: a suite that looks thorough because of its size, without anyone being able to say which parts of it are actually contributing to confidence in the code. Pruning it feels risky precisely because nobody has the data to prune it safely.
How Obvyr surfaces which tests are earning their keep
Obvyr builds a health profile for every test from its execution history: pass/fail counts, pass rate, flakiness, and the test’s full run history, filterable by status and date range so you can see how it’s behaved recently versus over its whole lifetime. Slowness ranking works the same way from the duration angle: it surfaces which tests have the longest execution times right now, and tracks how that duration trends over time, so a test that’s been quietly getting slower for months doesn’t just blend into a vague, suite-wide “CI feels slow” complaint.
Combined with the flaky-test detection covered in our flaky test reliability guide, health profiles give you a much clearer picture of which tests are stable, fast, and worth keeping as-is, and which are slow, unreliable, or both. Those are the ones most worth investigating first when you’re looking to cut CI time without cutting coverage that matters.
Prioritising what to look at first
Seeing pass rate, flakiness, and duration trend side by side turns a vague sense of bloat into an actual worklist, because those two signals don’t move together. A test that’s slow but rock-solid is a CI-time optimisation, not a trust problem (worth parallelising or trimming, but not urgent). A test that’s fast but flaky is the opposite: cheap to run, expensive to trust, and exactly the kind of thing eroding confidence in red builds elsewhere in your suite. Fast and reliable tests need no attention at all, which is itself useful information: it tells you where not to spend review time. The tests that are both slow and unreliable are the ones actually costing you twice over, and they’re the ones worth investigating first.
What this doesn’t do yet: Obvyr doesn’t currently perform automated test-value assessment (surfacing, on its own, which specific tests have caught real bugs historically). That’s on our roadmap. Today’s signal is health and slowness data: which tests are reliable and efficient, and which are quietly expensive. It’s a strong starting point for prioritising review, not a fully automated “delete this test” verdict.
Used well, this turns “we have hundreds of tests and no idea which matter” into a ranked list you can work through. Start with the tests that are both slow and unreliable, since those are the ones costing you the most for the least confidence in return.
This matters even more if your test volume is growing faster than your team can review it by hand, which is exactly the situation covered in reviewing AI-generated tests at scale.