Why Vitest Is Better Than Jest

Vitest is a simple testing library built on top of Vite which takes everything I love about Jest and brings it to the modern age of JavaScript. Everyone that has worked with Jest knows how much of a pain it is to work with ES modules, but Vitest makes it trivial. Vitest also adds many additional features and quality of life changes that make it better than Jest in my opinion.

📚 Materials/References:

🌎 Find Me Here:

⏱️ Timestamps:

00:00 - Introduction
00:44 - Create a vite project
01:33 - Basic vitest tests
05:51 - Test coverage reports
08:16 - Inline testing

#Vitest #WDS #Jest

[nikfp]

I'm seeing a lot of frustration from folks that are using Jest and don't see the benefit of converting to Vitest, so I thought I would share my experience when switching over. I'm working on a back-end Node API that exposes a Graphql endpoint, and also a Sveltekit project. I have used Vitest in both.

- When trying to work with Jest (and also Mocha) I experienced huge hurdles in working with ESM and typescript. The "solution" was to maintain a different tsconfig for testing as the production config, which means they could easily migrate away if I wasn't careful. Also modules in testing were compiling to commonjs and for production were compiling to ESM.
- My first attempt to fix this was to use Uvu and TSM together, and I was actually pretty impressed with it. However it is minimal, so any mocking or anything else I was doing needed to be done by hand. This was also an issue for front end testing in Sveltekit. Rather than reinvent the wheel, I gave Vitest a shot and it works great. I was able to get rid of the tsconfig.testing.json file entirely, and still make use of the larger Jest-like API offered by Vitest
- Initial test run performance of Vitest vs Mocha (which was similar to Jest when tested previously) were about the same. Uvu did actually go a bit faster right out of the gate, but not really enough to notice. (half a second or less difference) HOWEVER once the test runner was running in watch mode, Vitest was orders of magnitude faster than Jest and Mocha and about twice as fast as Uvu. I think this has to do with the Hot Module Reloading in Vite.
- When working in Sveltekit, Vitest just worked. Since Vitest uses the same Vite config, this wasn't all that surprising.

Overall I've been happy with Vitest and don't see myself going back to Jest any time soon.

[enyakstew]

I have been struggling for hours trying to setup a react app created with vite and jest until I came across this video. Thank you for this !

[MrWertixvost]

Your videos are so insanely good, with fast enough pace and clean speech…. Demon!:)

[steveh]

Just tried it out on the online emulator. So easy to mock an imported ES6 module, I'm switching. Thanks Kyle!

[jhannes]

I'd be interested in a more general video about testing libraries, their features and their tradeoffs.
And setups you can have, like Webpack + Mocha+Chai + React Testing Library.

[JoaoPaulo-oxpr]

I have lots of nightmares with configuration files for everything, whether it is Eslint, Tsconfig, BabelRC, webpack, there's pratically no material outside the docs about them, i was having so many issues trying to config jest for react/typescript vite builded projects. and then i found this video, you're a lifesaver.

[StephenMoreira]

Will check this out, Jest is my #1 pain point in my project.

[codehan]

What‘s your opinion to use vitest within a react project? What about snapshot tests? Is it possible with vitest? I don‘t really see a benfit to be honest. No configs is good but does it really work in larger projects?

[johnodonnell]

I was wondering how to keep test code out of the bundler. Thanks for describing the config that does that!

[SithLordBishop]

Love to see a follow up on how mocks work.

[michamazurkiewicz]

Man you are such a talented guy. You should prepare something more than just a sum function. For which test looks the same with jest. Boundled files? You should not even keep the test code together with the src to not increase package size. So that’s useless. I would like to see how can I mock with it different async calls, how to test api etc. very bad. Don’t be lazy.

[risitas]

The main struggle my team has with Jest is the memory usage.

We have 3500 tests and when we run them all, the process slowly eats up more and more ram until it reaches 20-25 GB. If you don't have enough ram, the OS starts to use the harddrive and the tests start to timeout because of the slow speed.

Vitest has not solved this issue. Last time I tried it, the process just hung indefinitely.

[marcosadriano]

Vite and Vitest save much time, another solution is Jest with SWC instead Babel, its runs really good too.

[joshuasmith]

I never had an issue using import in jest... so it is hard to argue for that to be the reason to switch. I'd be more interested to see how to test UI components with vitest.

[kirilltalalykin]

im confused about the part at 3:18, where you say import/export in test file is not available in jest. What do you mean by that. I never experienced any problem with jest test files and imports

[WilChow]

Another reason why I need to try out a project with Vite

[warrencedro]

This is great, could you make a video about Turborepo implementing Vite and Vitetest?

[bryson]

Damn, you convinced me. I'm switching. I like in line tests.

[yokiyu]

I think most of the products from vue team are opinionated, that's why vite or vitest seems less configuration files and easier to setup with, but the tradeoff is also exists behind the scene. From my experience, if you want to setup a well known structure that vite provides you then choose vite, but if you want to setup piece by piece and to have the most extendability then choose webpack rollup cra jest stuff like that. BTW, I don't think a little compile speed gain is worth changing to an opinionated architecture.

[vamshiart]

vitest has been very slow in CI pipeline, supposedly 2-3 times slower than jest. I am surprised no one talking about that. We moved to vitest, saw how slow it is and moved back to jest.