TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Vitest vs. Jest

44 pointsby ritzaco6 months ago

10 comments

mythz6 months ago
I prefer using bun:test [1] where possible, super fast to run, all built-in no need to install any packages, supports watch mode, also TypeScript tests just works out of the box without additional deps or steps. You&#x27;ll also get all the benefits of bun which is a breath of fresh air over npm.<p>[1] <a href="https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;cli&#x2F;test" rel="nofollow">https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;cli&#x2F;test</a>
评论 #42245765 未加载
评论 #42245807 未加载
OptionOfT6 months ago
Vitest does not support CommonJS mocking as of today.<p>I switched to Vitest because Jest was giving me flaky coverage results: <a href="https:&#x2F;&#x2F;github.com&#x2F;nodejs&#x2F;node&#x2F;issues&#x2F;51251">https:&#x2F;&#x2F;github.com&#x2F;nodejs&#x2F;node&#x2F;issues&#x2F;51251</a><p>And while Vitest&#x27; coverage is stable, I had to add an indirection layer to change how I mock out calls to GitHub&#x27;s API (@github&#x2F;octokit).<p>Oh, side note: vite-node&#x27;s --watch functionality does not restart the process. It does hot reloading which is different enough that it requires some rework at how you set up your app structure and callbacks.
评论 #42245924 未加载
britches116 months ago
We switched from Jest to Vitest this summer as part of the effort to migrate a large node repository to ESM. Jest presented a lot of issues after switching to ESM. Vitest was compatible with our existing jest code, minus a couple altered method signatures. It was also compatible with custom matchers we had implemented with jest-extend.<p>Most of the migration effort was spent on configuration for our needs. Vitest is quite flexible so it was just a matter of nailing down what worked for us.
streptomycin6 months ago
FWIW I tried switching a fairly large project from Jest to Vitest, hoping for performance improvements. Instead I got some inscrutable errors about circular dependencies.<p>More generally this is one of the really annoying things about Node.js. You might have some circular dependency that works everywhere, but it fails when you use some specific bundler or test runner. Cause they all handle things slightly differently.
评论 #42247755 未加载
thecopy6 months ago
Im interested if anyone has experience using node&#x27;s native test runner in a non-trivial project?<p>We are not using the module mocks from Jest in our project and a quick PoC showed significant (3x) speed improvement, but i am worried about the battle-tested:ness.
评论 #42245710 未加载
评论 #42246370 未加载
评论 #42247335 未加载
评论 #42245780 未加载
lscharen6 months ago
I just recently did a website conversion that used vite and took a look at both vitest and playwright.<p>Ended up going with playwright for the “batteries included” browser support and because we use .Net Core for the backend.<p>dotnet doesn’t always get the best support from pure JS&#x2F;TS projects, so it seemed like a reasonable hedge.
评论 #42247898 未加载
catlifeonmars6 months ago
What is meant by “interactive snapshot testing”? If this is the ability to generate and update snapshots in watch mode, Vitest supports this, even though the feature matrix in the article indicates that it does not. I know because I used this feature last month.
评论 #42246045 未加载
craftoman6 months ago
Why not use Node’s built-in testing platform with node --test for server-side purposes or small projects? You can run typescript too. The only drawback is the lack of an expect function, but you can easily built your own or use mine, it’s called tinyexpect.
petesergeant6 months ago
It’s fair to say I will never use Jest again where possible, instead preferring vitest
brianzelip6 months ago
Good write up that helps you get started if you haven&#x27;t used either lib.