I don't get how a test runner can be "ultra fast". Surely all the time is taken by the tests, not calling the test functions?

▲

andrewingram 3 hours ago | parent | next [-]

At work we've tried switching to vitest, and it's 1.5-2x slower than Jest (I think it's related to our very large and circular module graph), so performance is very much a your-mileage-may-vary thing.

	▲	streptomycin 2 hours ago \| parent \| next [-]
		The initial selling point was performance, but then they gradually realized that a lot of the slow cruft in Jest was necessary for correctness, and now it's about the same performance as Jest (obviously may vary in some specific situation). However vitest is still great! Selling points now are stuff like: - shares config with vite - works with ESM out of the box (I think Jest still doesn't) - integrated browser testing mode that is very nice - overall just has a ton of nicely integrated features
	▲	bhouston 2 hours ago \| parent \| prev [-]
		I do recommend turning off "isolate" for as much of your code base as possible when it makes sense. And I recommend ensuring "maxWorkers" is being used properly, I prefer something like 60% of my totals cores as the number of workers to use. And use a top level vitest start so it properly runs all the packages in a pipeline rather than as separate vitest runs (which would mess up the maxWorkers optimization anyhow.) I have my 3000 test project suite completing in 15 seconds on my MacBook Air M3. It is pretty sweet with that setup.

▲

sunaookami an hour ago | parent | prev | next [-]

Say this again when you have worked with Jest, one of the worst and slowest pieces of software I've ever worked with.

	▲	johnfn 34 minutes ago \| parent [-]
		And Jest was itself a huge step up from what came before (Jasmine, Mocha...)

▲

re-thc 2 hours ago | parent | prev [-]

> Surely all the time is taken by the tests, not calling the test functions?

Calling tests has overhead. Also knowing how to schedule and parallelize tests with dependencies is not as "simple".