I am investigating what is the faster and has a smaller memory footprint compare to Vitest, any recommendation?

[kasir-barati]

Hi guys,

I know this might not be the best way to approach this but I was wondering if we have a faster test runner I can use in My NodeJS and Frontend projects written in TS/JS. Right now the bigger the project the longer it takes to finish all the unit tests. I know I can use and probably must use something like Nx to just run those tests which hae been affected. But I would still like to know if there is a faster test runner in NPM echo system (or if possible outside of it) to run my tests faster with smaller memory footprint.

In Vitest we can use --smol, but there's an important catch: --smol is a memory optimization, not a performance optimization. AKA I am afraid of making the execution even slower because garbage collection happens more aggressively.

I have looked at rjest, but I am unsure still about it. Any comment?

I also am considering if I should use Bun, but then we really do not have the Vitest/Jest echo system: https://www.misar.blog/compare/vitest-vs-bun-test

So what are your take on this?

[kasir-barati]

BTW I have asked same question in Jest since there was not really a clear answer to my question:

• I am investigating what is the faster and has a smaller memory footprint compare to Jest, any recommendation? jestjs/jest#16467
• I asked about it in ChatGPT and the results are not satisfactory at all (maybe my prompt is not really the best): https://chatgpt.com/share/6ab91353-c7e4-83ed-98e1-bf5bb4846d5a

My Goal

• Faster execution speed.
• Smaller memory footprint.

In a large project with many test suites

[aashish254]

Before switching test runners, it's usually worth checking if the bottleneck is Vitest's default per-file isolation. In larger projects, recreating the test environment for every single file is what eats up most of the execution time and memory.

Here's a straightforward approach to look into:

1. Optimize Vitest first:

• Run npx vitest doctor: It automatically benchmarks your suite under different flags to show what actually speeds it up.
• Try --no-isolate: If your tests don't leak global state into each other, disabling isolation is usually the single biggest speed and memory improvement.
• Switch from jsdom to happy-dom: If you're doing frontend testing, happy-dom is significantly lighter and faster to spin up.
• Lower maxWorkers: Throwing more CPU cores at Vitest can counterintuitively slow it down because workers funnel module transforms through a single Vite thread.

2. Alternative options & trade-offs:

• node:test (Node's built-in runner): By far the lightest and fastest choice for pure JS/TS logic with virtually zero overhead. However, you lose Vitest's DOM ecosystem, vi.mock(), and built-in matchers.
• bun test: Very fast execution and low memory usage, but it runs on the Bun runtime rather than Node, so browser/DOM mocking and Jest-compatible APIs can behave differently.

If it's a frontend project, tweaking Vitest's isolation and worker settings usually gives you the speed boost without breaking your setup. If it's pure Node backend or utility code, node:test is hard to beat for raw performance.