Post

Switched to vitest a long time ago, was a little apprehensive since it was relatively new, but never looked back since then!

Nicolas Dubien

@nicolas.dubien.me

If only the 'feature buffet' of @vitest.dev also came with Property based testing (aka fuzzing) backed by @fast-check.dev. It's probably one of the key testing features they miss in their impressive toolset

Nicolas Dubien

@nicolas.dubien.me

github.comBuilt-in support for Property Based Tests (aka Fuzzing) · vitest-dev vitest · Discussion #2212Hey 👋, I'm Nicolas, core maintainer and main contributor to the project called fast-check. The project does property based testing and reaches 650k downloads a month at the moment. In a nutshell: P...

While considered as a niche feature by some it's one of the most up-voted discussions on the repo · github.com/vitest-dev/v...

Nicolas Dubien

@nicolas.dubien.me

Forgot to say: Great post! Really nice to read!

Emanuele (Ema)

@ematipico.xyz

A couple of questions: - Isn't "multi-thread mode" misleading? Shouldn't it be called "multi-cpu mode"? - Regarding vm.Module not supporting ESM, it's unfortunate. Shouldn't this be a call out for Node.js overlooking ESM in important parts of the runtime?

Why do you think multi-thread is misleading? It’s using node worker threads. Node VMs support ESM but it’s experimental. + conceptually speaking node VM isolation is prone to memory leaks as imported modules might have side effects etc…

Emanuele (Ema)

@ematipico.xyz

That's on me, I still thought that works threads were using CPU cores instead of real threads

AriPerkkio

@ariperkkio.dev

Great post! Vitest does indeed allow users to choose the isolation mode and parallelization method (process, threads) based on their needs. The VM isolation on Vitest has same issues as Jest; node:vm leaks memory and we need to restart forks/threads when a certain limit is reached to prevent OOM.

Thank you so much Ari, it's humbling to get such feedback from you! 🙏

AriPerkkio

@ariperkkio.dev

Choosing between forks or threads is also great, as there are many packages that cause segfaults when run on 'node:worker_threads'. Typically these packages are built using Node-API with C++/Rust/Go. We've listed such packages in github.com/vitest-dev/v.... None of those packages crash with forks.

Good point! I should add this.

AriPerkkio

@ariperkkio.dev

It's also worth to note that comparing non-isolation mode against Jest isn't really fair, and we've seen even ~10x faster execution times on Vitest without isolation: github.com/vitest-dev/v... Though I think there is a community-driven Jest runner that provides non-isolation mode there too.

Absolutely! You are referring to this I guess: github.com/nicolo-ribau... I did my best to stay as fair as possible by including benchmarks of different isolation modes + cold start vs. warm.

Lars Hanisch

@flensrocker.de

I think I have to learn how to switch my Nx monorepo from jest to vitest, esp. because I need ES2022 to compile my code and Jest has problems with async tests (some weird Angular error about "ProxyZone" I don't remember...).

If you’re not in a rush and can wait few days. I am working on a migration guide that should help you. Hard to speculate on the root cause of the ProxyZone but in testing it sometimes related to async/await not being downgraded… and both jest preset angular & vitest plugin handle that properly.

Lars Hanisch

@flensrocker.de

Yep, it has something to do with async/await. No hurry, I have enough to do in the meanwhile... 😎