The Dirty Secret of Modern Test Runners: Over-Isolation by Default

Here is the uncomfortable truth: your test suite isn’t slow because you have too many tests. It’s slow because your test runner is doing expensive work your code never asked for.

Every major frontend testing framework — Jest, Vitest, Playwright, and their peers — applies aggressive isolation by default. Before each test runs, the framework spins up a fresh environment, resets global state, and sandboxes execution so nothing bleeds between tests. That sounds responsible. The problem is that this machinery fires whether your test touches shared state or not. A pure function that transforms a string gets the same isolation treatment as a stateful authentication flow. The overhead is identical. The necessity is not.

The cost compounds fast. Spin-up time, module re-evaluation, environment teardown — multiply that across hundreds or thousands of tests and the numbers get ugly. A suite of 1,000 tests running in 30 seconds isn’t suffering from test volume. It’s paying the isolation tax 1,000 times in a row, mostly unnecessarily.

Preact’s test suite makes this visible. All 1,003 tests — running in a real browser against a real DOM — complete in approximately one second. That result caused genuine shock when it circulated online, which itself reveals how normalized slow test execution has become. Developers accepted two-minute CI feedback loops as the price of thoroughness. They aren’t. They’re the price of uncritical defaults.

Test isolation is not inherently bad. State leakage between tests causes flaky, unreliable results, and catching that matters. The failure is treating isolation as a zero-cost universal requirement rather than a targeted tool. When frameworks bake maximum isolation into every test run by default, they shift the burden onto developers to opt out — and most developers never do, either because they don’t know they can or because the configuration cost feels high. The result is entire codebases running unit tests for stateless utilities through the same heavyweight gauntlet designed for integration tests. Speed is the casualty.

What Preact Actually Did: Opt-In Isolation Instead of Opt-Out

Preact’s entire test suite — 1,003 tests — completes in approximately one second. Those tests run in a real browser against the real DOM. There is no JSDOM simulation, no synthetic environment papering over browser quirks, no shortcuts that trade accuracy for speed. The fidelity is full, and the speed is still there.

The reason comes down to a single architectural decision: isolation is opt-in, not opt-out.

Most modern test frameworks treat isolation as a universal default. Every test gets a fresh module registry, a clean environment, and a hard boundary separating it from every other test. The logic sounds reasonable — isolation prevents tests from contaminating each other. The problem is that this protection has a cost, and that cost gets paid whether the test needs the protection or not. Spinning up isolated contexts, reloading modules, and resetting state on every single test adds overhead that compounds across a suite. Run 1,000 tests that way and the milliseconds stack into seconds, then tens of seconds.

Preact’s approach inverts the default. Tests share an environment unless a specific test has a genuine reason to demand its own isolated scope. The vast majority of test cases — the ones checking rendering behavior, DOM output, component lifecycle, event handling — do not produce state that bleeds into neighboring tests. They run, they assert, they finish. No teardown theater, no module reloading ceremony.

When a test actually requires isolation — because it mutates globals, patches module internals, or tests behavior that genuinely cannot coexist with shared state — that test opts in. It pays the isolation cost intentionally, because the cost is justified.

This is not a trick for making test execution faster at the expense of correctness. The JavaScript test performance gains come from eliminating waste, not from weakening guarantees. Shared-environment test execution at this scale demonstrates that the overhead baked into popular frontend testing tools reflects a philosophical assumption — that isolation is always necessary — rather than a technical requirement. Preact’s suite proves that assumption wrong 1,003 times per second.

Why This Matters Beyond Preact: The Developer Feedback Loop Problem

Test-driven development only works when the feedback loop is tight enough to change developer behavior. When a test suite takes five minutes to run, developers stop running it after every change. They batch their work, run tests at natural breakpoints, and discover bugs later — sometimes much later. That delay is where debugging time compounds and confidence in refactoring erodes.

Preact’s 1,003-test suite completing in approximately one second is not just a performance curiosity. It demonstrates what becomes possible when testing speed matches the rhythm of active coding. At that latency, running tests after every meaningful edit costs nothing psychologically. Developers don’t schedule test runs — they just run tests, constantly, the same way they save files. Regressions surface within seconds of introduction rather than at the end of a sprint.

The reaction to Preact’s numbers spreading on social media was revealing. Many working frontend developers said they had never experienced a test suite that fast. That’s a significant admission. It means an entire generation of developers has normalized slow continuous integration pipelines and multi-minute local test execution as the baseline cost of software quality. They’ve built workflows around waiting — and those workflows quietly reduce how often they verify correctness.

This problem isn’t unique to Preact’s ecosystem or to JavaScript frameworks. Any codebase where the automated test suite runs in minutes rather than seconds carries the same hidden tax on developer productivity. The unit testing cycle, integration testing cadence, and the overall test execution speed all shape whether test-driven workflows are genuinely sustainable or just theoretically endorsed.

The practical implication is that test suite speed is not a secondary concern — it’s a first-order design decision that determines how closely quality verification tracks actual development. A sub-second feedback loop turns tests into a real-time safety net. Anything slower turns them into a checkpoint, which is a fundamentally different and less effective tool.

What Most Coverage Is Missing: This Is a Design Philosophy, Not a Performance Trick

The conversation around faster test execution almost always lands in the same place: better hardware, smarter caching, more parallelism. Preact’s 1-second run across 1,003 tests arrives from a completely different direction. The speed is a byproduct of a deliberate design decision — not a technical optimization layered on top of an existing architecture.

The decision is this: most code does not require the level of test isolation that modern test runners apply by default. Popular frontend testing frameworks treat maximum isolation as the safe universal baseline. Every test file gets its own module registry, its own environment spin-up, its own teardown cycle. That overhead is justified when tests genuinely need it. Applied universally, it becomes a tax on every test in your suite, including the thousands that never needed that protection in the first place.

This is defensive over-engineering institutionalized as a default. The tooling ecosystem built for worst-case test scenarios and then shipped that configuration to everyone. Developers running unit tests against pure functions pay the same isolation overhead as developers testing genuinely stateful, side-effect-heavy code. The costs compound silently across every test run, every save, every CI pipeline trigger.

What Preact demonstrates is precision engineering in the opposite direction. Isolation is opt-in, applied where the specific test actually requires it. The test environment matches the real problem: browser-based execution against a real DOM, with shared context where sharing is safe. That calibration — matching tool capability to actual requirement rather than theoretical maximum requirement — is what produces the benchmark, not raw compute speed.

The practical implication for software development workflows is significant. When test feedback cycles stretch from seconds into minutes, developers stop running tests continuously. They batch their runs, context-switch away, lose the tight loop between writing code and verifying behavior. A test suite philosophy built on selective isolation restores that loop. The speed is a consequence of accuracy — accurately identifying what each test actually needs, and refusing to spend resources on isolation overhead it does not.

What Developers and Teams Should Take Away Right Now

The first thing to audit is not your CI pipeline or your hardware — it’s your assumptions. Walk through your existing test suite and ask a blunt question about each test: does this actually need a fresh browser context, a new module scope, or a clean global state? Most tests don’t. They inherit full isolation because the test runner applies it by default, not because the test logic demands it. That distinction is where most of the performance is hiding.

Treat test suite execution time as a first-class engineering metric, the same way you treat code coverage percentages and assertion correctness. A test suite that takes three minutes to run is not a sign of a thorough test suite — it is a sign of misconfigured tooling. Slow feedback loops compress the number of times a developer runs tests locally, which compounds into slower iteration cycles, more context-switching, and bugs that survive longer than they should. Speed is not a luxury concern; it is a reliability concern.

The Preact test suite makes this concrete and reproducible. One thousand and three tests, running against the real DOM in a real browser, completing in approximately one second. That result exists today, using existing browser technology, without exotic infrastructure. The gap between that benchmark and what most frontend testing frameworks deliver by default is not explained by test complexity — it is explained by default isolation settings that no one has revisited.

The practical starting point for any team is categorization. Separate tests that genuinely require isolated state from tests that simply tolerate it. Opt into per-test or per-file isolation only where contamination between tests is a real risk. Shared module scope and shared DOM context, cleaned up manually between tests where needed, dramatically reduce the per-test overhead that accumulates across large suites.

Fast test execution, accurate test results, and genuine browser environment fidelity are not trade-offs. Preact’s approach demonstrates they coexist. The barrier is not technical — it is the unquestioned acceptance of slow defaults.