I am investigating what is the faster and has a smaller memory footprint compare to Jest, 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.

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 Jest's echo system: https://app.studyraid.com/en/read/11127/344668/comparing-bun-with-jest

So what are your take on this?

[kasir-barati]

BTW I am also asking the same question in Vitest since I was not able to find a good answer to this question:

• I am investigating what is the faster and has a smaller memory footprint compare to Vitest, any recommendation? vitest-dev/vitest#11368
• 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

[muhammadmobi]

Before you switch runners, it's worth trying Jest 30's own speed and memory settings. Most of the cost in a big TS suite is transpilation and memory held between test files, not the runner itself.

1. Upgrade to Jest 30 if you're on 29 or older. The release post describes the new module resolver and memory work (one large TS app reported 37% faster runs and 77% lower memory).

2. Turn on globals cleanup. It releases memory between test files. The default 'soft' mode only logs JEST-01 warnings, so fix any warnings first, then:

// jest.config.js
module.exports = {
  testEnvironmentOptions: { globalsCleanup: 'on' },
};

3. Cap worker memory. workerIdleMemoryLimit restarts a worker once it goes over the limit after a test file. That's the documented workaround for heap growth (#11956):

module.exports = { workerIdleMemoryLimit: '512MB' }; // or '50%' of system memory

4. Transpile with SWC instead of ts-jest/Babel. @swc/jest is a drop-in transform:

module.exports = {
  transform: { '^.+\\.(t|j)sx?$': '@swc/jest' },
};

5. Run fewer tests, and in parallel. You don't need Nx for this. Jest's built-in --onlyChanged / --changedSince=origin/main runs only the tests affected by your changes. In CI, --shard=1/4 splits the suite across machines. --maxWorkers sets the parallelism on each machine.

Measure before and after: node --expose-gc ./node_modules/.bin/jest --runInBand --logHeapUsage prints the heap after each test file, so you can see which files leak before deciding whether a new runner is really needed.

[ado11231]

If your main goals are execution speed and lower memory usage, I think Bun is worth testing against your actual project. Its test runner supports a Jest API, TypeScript, snapshots, mocks, DOM testing, workers, and sharding, although Jest compatibility is still not complete.

I would not choose a runner based only on published benchmarks though. For a large codebase, dependency loading, transforms, DOM environments, isolation, mocks, and worker configuration can have a bigger impact than the test runner itself.

A useful comparison would be to run the same representative suites with Jest, Vitest, Bun, and rjest and measure the following:

• Cold full-suite execution time
• Warm/watch-mode execution time
• Peak memory usage
• Performance with different worker counts
• Compatibility issues and required test changes

You can often try bun test on existing Jest tests without fully migrating the project first.

For very large monorepos, I would still combine the faster runner with affected-test selection or sharding. A faster runner helps, but avoiding unnecessary tests usually gives a much larger improvement as the project grows.