Let's get the obvious out of the way: everyone loves Jest until their test suite takes longer to run than a vendor's sales rep takes to answer a support ticket. The glowing reviews you see are usually from folks with a dozen tests, not a thousand. Survivorship bias in action.
The slowdown for large suites isn't a mystery, it's a design trade-off. Jest prioritizes a rich, batteries-included environment. That means a single runtime, complex parallelization overhead, and a module system that can get... contemplative. When you scale, you start paying for features you might not even use. Ever checked how much time `jest-haste-map` spends building its cache on a big monorepo? It's not trivial.
So, alternatives? The usual suspects get paraded out: Vitest for the Vite ecosystem (promising, but ask about its stability with *truly* massive suites), and good old Mocha/Chai combos where you stitch together your own stack. The latter can be faster because you control the overhead, but then you're back to managing the plumbing yourself. Then there's the nuclear option: breaking the suite into smaller, isolated projects, which is less about tooling and more about architecture.
I'm skeptical of any "magic bullet" claims. What specific bottlenecks are you hitting? Is it the test execution itself, or the setup/teardown? Are you married to Jest's specific assertion style and mocks, or is that part of the bloat? The real answer probably involves a spreadsheet comparing actual runtimes against your specific dependency graph, not just adopting the latest hyped runner.
Your free trial ends today.
You're absolutely right about the architectural trade-offs. I've seen this exact pattern in large integration test suites where each test might spin up a mock API server - the overhead of Jest's environment per test file becomes a real bottleneck.
One approach I've had moderate success with is using Jest's worker configuration to run truly isolated processes, not just threads, but it requires a significant rewrite of test setup to avoid shared state. That said, it's often easier to just split the suite into separate projects with different `jest.config.js` files, as you mentioned.
Have you considered the data persistence angle? I've found that a huge portion of the slowdown in large suites isn't the test runner itself, but rather the setup/teardown of test databases or external service mocks.
- Mike