CI test suites: parallelization, flaky-test quarantine, and fast feedback

A test suite that takes 45 minutes to run in CI doesn't just cost 45 minutes once — it costs 45 minutes on every single change, multiplied across every developer, every day, for as long as the suite stays that slow. Slow feedback has a real, compounding cost beyond the raw time: developers start batching more changes into fewer, larger PRs to amortize the wait, which makes each individual PR harder to review and more likely to contain an unrelated regression buried inside a big diff. A fast suite isn't a nice-to-have polish item — it's a direct input into how safely and how often a team can actually ship.

Because well-written unit tests are isolated by design (no shared, unreset state between them — the exact property the flaky-tests lesson already argued for on correctness grounds), they can safely run concurrently, in any order, across multiple machines or processes at once — a 40-minute suite split evenly across 4 parallel workers finishes in roughly 10. This is a second, very concrete payoff of test isolation beyond just avoiding flakiness: a suite that depends on execution order or shared state generally can't be parallelized safely at all, since running two order-dependent tests concurrently on different workers can produce a genuinely different (and wrong) result than running them sequentially.

A known-flaky test blocking every single merge in the repository until someone gets around to fixing it is a real, practical problem — but silently deleting it, or leaving it in the suite for everyone to keep re-running and ignoring, both throw away real signal along with the noise. Quarantining a flaky test — marking it explicitly as known-unreliable, tracked with a ticket, excluded from blocking merges but still visible in CI output — is the honest middle path: it stops one broken test from stalling the whole team, while keeping the problem tracked and visible rather than quietly forgotten, which is exactly what happens to a flaky test nobody's explicitly made responsible for fixing.

Running the slowest checks first means a trivial typo or lint error isn't discovered until after the expensive E2E suite has already finished — wasted CI time and a much longer wait to learn about a problem that could have been caught in seconds. Ordering CI stages from fastest/cheapest to slowest/most-expensive, and failing (or at least reporting) as early as possible, is a direct application of the same idea the very first lesson in this domain opened with: catch problems at the cheapest possible point — here applied to the pipeline's own structure, not just to when a bug is introduced.