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.
Jest has an issue to solve ESM for 4 years, that is 1 reason I never use Jest anymore, but Vitest for frontend and the native Node test runner for backend and packages. If you want test ESM with Jest, it compiles it indeed to commonjs, but that is not a real world test for me, because I use ESM in production in the backend. So Jest was for me not useful to test if it works, because you test something different than what we run. if you build something with a build step, like most frontend applications, it is a different situation. But be careful, that the test should build the same as you do in production. But in the backend and packages I never add a build step anymore, so everything is much more simple, and also a lot faster. You can just test the code without waiting on the build.
I'm back in the Node.js world again after some time working in Golang and I just got reminded how much I hate Jest... Constant import errors and super terrible TS support
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.
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.
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?
I would just test the UI by looking at it, separated from logic (with mock data) and test functionality, but I don't do automatic testing on my project yet tho
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.
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.
@@LordSuperAstro It is not. jest is simply utterly slow to run tests. We have over 6K tests and it just takes 2 hours on dev machine to run all test cases and most of the time it fails due to timeouts
@@vickylance If what you're testing isn't already CPU intensive then it's maybe a GC problem. Maybe try to be more conservative with allocations. Not saying it's not a problem with the framework but maybe you can circumvent it with good programming.
@@parlor3115 the problem is react takes a lot of time to render per test in jest, and 250 frontend devs writing code tests can't be checked for maximum efficiency every time. Even when I just run one test it takes a lot of time to even start the test.
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.
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.
How do you create your react projects? Using vite ? or create-react-app? Because I just had a lot of problems with import.meta statements in vite/react projects while working with jest.
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.
You got a point but the less opinionated a framework become the more ways the code can branch into multiple paradigm that if left unchecked, will become more harder to maintain in the future. This is why most frameworks tends to favor convention over configuration. But then a good framework always adopts good convention or best practices by the community while also leaving spaces for configuration.
@@daleryanaldover6545 TIL! Can't agree with you more, especially “a good framework always adopts good convention or best practices by the community while also leaving spaces for configuration”.
Let me ask about the parameter with the spread operator (...numbers).... Are you doing it like this so you are not mutating the argument that is sent to the function? Is this because of a good practice to avoid changing the arguments reference?
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
Personally I'm really happy with Jest + React Testing Library but I'll give this a shot. I don't really see a benefit with inline testing though. If you have several small files I'd rather put the test files in a __tests__ folder.
Hi Renoistic ! Do you have any source or good tutorial to learn Jest and React Testing Library ? I'm trying to learn it but it's a pain to find any meaningful source, and the doc is a mess. Thanks !
I don't doubt there might be some benefit on using vitest, but I doubt it compensates the inflated cost of finding a vitest developer over a jest developer, or having to train people on it. After 10 years trying everything, I've settled with react + express/django + jest because it does what it is supposed to, and they don't break stuff. And those who had to migrate from angularjs to angular know what I'm speaking about.
It only includes tests that are inline, meaning the ones you write in your main .js or .ts files. Vite doesn't include the ones from test files as far as I know.
Jest is very simple already. I’m surprised there is a concern that it’s too complicated. Using babel-jest you can compile down your test code which automatically gives support for modern JS including import/export.
Hey Kyle! I watched your video and it is awesome. Now I am using the Vitest in my project but I am getting this error : ( Not implemented: window.computedStyle(elt, pseudoElt) at module.exports (C:\Users\Faizan\Desktop\full-stack ode_modules\jsdom\lib\jsdom\browser ot-implemented.js:9:17) )
hi in one folder all of my test file are running parallel , so for testing database conflict data and failed many test. but when I run one file at a time all test are passing. how are configure vitest in a way so that it only run one testfile at a time?
Can you show us this with a normally setup typescript project. I keep getting errors. When using Vite it is pretty seemless though. Edit: Wow it just fixed itself after restarting the IDE. A developer problem needs developer solutions lol.
Ah something new and old... I've been web dev-ing for almost a year now and never used jest, or maybe have but I have no idea when. Or what it even does
I'd be interested to see how Vitest handles error reporting. Jasmine / Karma is fucking horrible with presenting errors in a comprehensive format. You can spend hours trying to find out what's wrong. Jest has been slightly better over the last year. Wonder how good this is when you're working with subscriptions, fake async zones, state etc.
If it is quicker than jest AND integrate will in an existing project not using vite it might be worth a try, otherwise no. Does someone here using it in a real world project that does not use vite and can compare with jest?
The main audience here seems to be developers of frontend apps using Vite. I get the appeal of not wanting to double-configure some things, it makes makes sense. But I can't find a reason to want to switch otherwise, maybe I need to be using Typescript (which is just overkill for what I'm working on these days). Inline tests look nice with the small simple example, but most functions/modules worth testing can quickly end up having hundreds of lines of testing code; I would not want that mixed up with the module itself. Moreover, I wouldn't want to sometimes do inline tests and sometimes not as that is confusing. Also, it looks and feels super hacky to set up this feature with the "define import.vitest = undefined" stuff. I get why it works, but if the configuration on Vitest is so good, why do I have to do something hacky like this at all for such an obvious use-case? Kind of makes me lose confidence with what else might be hiding in the configs. I'm not convinced to switch, I'd rather deal with the rather minimal jest configuration (Vitest doesn't seem to spare me much work at all) than get another opinionated mess from the Vue team. This feels like the Vue team trying to rope developers in more and more to a Vue ecosystem just for the sake of being in that ecosystem without adding much value. They are a hard working team that has helped push some things in the field forward, but for my preferences, they have also consistently picked poor and confusing abstractions that have caused me more headaches than problems solved, why would I want to switch if I'm not using Vite?
If vitest is the same API as jest, it doesn't really solve the issue with jest's convoluted mocking system which makes it a pain to spy on default function exports. I get that it's faster, but it doesn't look like the jest killer that we need.
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.
Jest has an issue to solve ESM for 4 years, that is 1 reason I never use Jest anymore, but Vitest for frontend and the native Node test runner for backend and packages.
If you want test ESM with Jest, it compiles it indeed to commonjs, but that is not a real world test for me, because I use ESM in production in the backend.
So Jest was for me not useful to test if it works, because you test something different than what we run.
if you build something with a build step, like most frontend applications, it is a different situation.
But be careful, that the test should build the same as you do in production.
But in the backend and packages I never add a build step anymore, so everything is much more simple, and also a lot faster.
You can just test the code without waiting on the build.
I'm back in the Node.js world again after some time working in Golang and I just got reminded how much I hate Jest... Constant import errors and super terrible TS support
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 !
Just tried it out on the online emulator. So easy to mock an imported ES6 module, I'm switching. Thanks Kyle!
that's good to hear! I was just wondering if mocking with vitest was easy.
Of course you can have your opinion but why do you think mocking with jest is hard/complicated?
Aaaand I've now switched back to Cypress
@@steveh7922 What happened? XD
@@steveh7922 Lmao, what happened?
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.
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.
I feel your pain
Will check this out, Jest is my #1 pain point in my project.
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?
Wanna knows these too
Don't using react but After a short look at the docs that looked good for react and i'm already using it in a large projet and it juste work great
vitest does jest-compatible snapshot testing, as I understand it, though I've never tried to see how compatible it is.
I would just test the UI by looking at it, separated from logic (with mock data) and test functionality, but I don't do automatic testing on my project yet tho
@@mathnewph are you using react testing library? is it possible to extend vitest expect with jest-dom matchers?
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.
I was wondering how to keep test code out of the bundler. Thanks for describing the config that does that!
Vite and Vitest save much time, another solution is Jest with SWC instead Babel, its runs really good too.
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.
sounds like something is wrong with your tests
@@LordSuperAstro It is not. jest is simply utterly slow to run tests. We have over 6K tests and it just takes 2 hours on dev machine to run all test cases and most of the time it fails due to timeouts
@@LordSuperAstro We spent weeks trying to find a cause and we never did. As @Vickylance said, it's a problem with jest.
@@vickylance If what you're testing isn't already CPU intensive then it's maybe a GC problem. Maybe try to be more conservative with allocations. Not saying it's not a problem with the framework but maybe you can circumvent it with good programming.
@@parlor3115 the problem is react takes a lot of time to render per test in jest, and 250 frontend devs writing code tests can't be checked for maximum efficiency every time. Even when I just run one test it takes a lot of time to even start the test.
Love to see a follow up on how mocks work.
Currently stuck on how to mock using their test runner. Hope he does an update
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.
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.
How do you create your react projects? Using vite ? or create-react-app? Because I just had a lot of problems with import.meta statements in vite/react projects while working with jest.
Your videos are so insanely good, with fast enough pace and clean speech…. Demon!:)
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.
You got a point but the less opinionated a framework become the more ways the code can branch into multiple paradigm that if left unchecked, will become more harder to maintain in the future. This is why most frameworks tends to favor convention over configuration. But then a good framework always adopts good convention or best practices by the community while also leaving spaces for configuration.
@@daleryanaldover6545 TIL! Can't agree with you more, especially “a good framework always adopts good convention or best practices by the community while also leaving spaces for configuration”.
Damn, you convinced me. I'm switching. I like in line tests.
Let me ask about the parameter with the spread operator (...numbers).... Are you doing it like this so you are not mutating the argument that is sent to the function? Is this because of a good practice to avoid changing the arguments reference?
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
I was about to ask the same, I use ESModules with Jest all the time, never had a problem...
This is great, could you make a video about Turborepo implementing Vite and Vitetest?
Hey Kyle, please make a similar video for end to end testing using react native expo+ detox, it would be of great help
Thank you so much) Very helpful!
Another reason why I need to try out a project with Vite
Personally I'm really happy with Jest + React Testing Library but I'll give this a shot. I don't really see a benefit with inline testing though. If you have several small files I'd rather put the test files in a __tests__ folder.
Hi Renoistic ! Do you have any source or good tutorial to learn Jest and React Testing Library ? I'm trying to learn it but it's a pain to find any meaningful source, and the doc is a mess. Thanks !
Udemy
the benefit is that they are easily accessible, tests are meant to be partly a form of documentation
@@Cowkill try kent c dodds courses, they've helped me a lot
Is it?My first impression in March that it wasn’t
I don't doubt there might be some benefit on using vitest, but I doubt it compensates the inflated cost of finding a vitest developer over a jest developer, or having to train people on it.
After 10 years trying everything, I've settled with react + express/django + jest because it does what it is supposed to, and they don't break stuff.
And those who had to migrate from angularjs to angular know what I'm speaking about.
Why is Typescript not complaining when you call sum without any arguments? The function should only accept an array with numbers. What am I missing?
strictNullChecks in the tsconfig is false by default. Setting it to true should make TS highlight that as an issue 😁👍
That's Awesome...
Thank you for the excellent content❤
Hey nice video, help a lot.
Who to have the `describe`, `expect`, `test`/`it`, etc... global? 😅:)
Thanks!
Welcome!
I'm getting an error "No test suite found in file .../vite.config.ts" Can't seem to find a solution :(
How to configure MUI testing in this project and show me how to run single test. Good content. Love your presentation.
Why is vite including tests in the bundle if it was not exported? How does work tree shaking in vite? Not based on exports & imports?
It only includes tests that are inline, meaning the ones you write in your main .js or .ts files. Vite doesn't include the ones from test files as far as I know.
Jest drives me mad. Ill have to play with this! Love Vite!
Amazing content bro love it keep it up
Jest is very simple already. I’m surprised there is a concern that it’s too complicated. Using babel-jest you can compile down your test code which automatically gives support for modern JS including import/export.
doesn't this cram test code into the bundler
Buddy you are amazing, keep rocking 👍
Vitest is sooooo fast! I'm loving it!
Can you do it with react components
Anthony Fu the best 🚀
Real world question: How Vitest goes with Mock/Spy and these things for "advanced"
Whats the best approach to add vitest into an EXCISTING project?
Well explained
Hey Kyle!
I watched your video and it is awesome. Now I am using the Vitest in my project but I am getting this error :
( Not implemented: window.computedStyle(elt, pseudoElt)
at module.exports (C:\Users\Faizan\Desktop\full-stack
ode_modules\jsdom\lib\jsdom\browser
ot-implemented.js:9:17) )
What import / export issues in Jest?
I can't able to install create react app with yarn which step of command i have to follow
hi in one folder all of my test file are running parallel , so for testing database conflict data and failed many test.
but when I run one file at a time all test are passing.
how are configure vitest in a way so that it only run one testfile at a time?
Jesus so fast and helpful information ❤
Do you have in depth explanation and examples about diff of toBe and toEqual?
Where do I configure vitest for In-source setup on vanilla JS
where do i put "types": "vitest/importMeta"
Am i right that apis are methods properties from a library or framework and URLS like rest
interesting ill give it a go
I saw this video and thought it would be cool to use it in node. But it has not been smooth sailing. Can you do a video for vitest on nodejs?
Import in jest is supported.
Been using it since 0.1 Never going back to Jest.
Im hoping that there will be a Vue content from you. 😊
👏
Can you show us this with a normally setup typescript project. I keep getting errors. When using Vite it is pretty seemless though.
Edit: Wow it just fixed itself after restarting the IDE. A developer problem needs developer solutions lol.
Please make a video on dataset in javascript I am really confused.
Is vitest faster than jest with SWC (Rust)?
that's awesome
11:32 .. easy way of fix that is go after build to production code and erase the test code from the compiled code-soup ._.
Ah something new and old... I've been web dev-ing for almost a year now and never used jest, or maybe have but I have no idea when. Or what it even does
But axios isn’t version 1 yet. It hasn’t been for years
I'd be interested to see how Vitest handles error reporting. Jasmine / Karma is fucking horrible with presenting errors in a comprehensive format. You can spend hours trying to find out what's wrong. Jest has been slightly better over the last year. Wonder how good this is when you're working with subscriptions, fake async zones, state etc.
Can I use vitest in the existing webpack project (without vite)?
I don't think vitest will add support to webpack, it would be like giving people more reasons to just stay using webpack.
@@daleryanaldover6545 ok thanks!
What's the benefit of using inline-test?
does anyone here not use any testing library, but use only console.assert with conditionals that run in dev but not in prod? seems lot simpler
amazing
Vite created by vue framework creator 🔥😍
If it is quicker than jest AND integrate will in an existing project not using vite it might be worth a try, otherwise no. Does someone here using it in a real world project that does not use vite and can compare with jest?
awesome
How hard to move from jest to vitetest
Pathfinder visualizer project with Vanilla javascript
"it's superfast, it took only 2ms" to sum 2 and 2 ;/ At least try summing a couple thousand numbers
Good, but frequently transition on every new tech is bad
💯
Nice hair style
when adding vitest my eslint fail,
scarxlus when u became web dev??
nee more video from vitest
Hello, whats about vitest + react native? Ty
After verification seems Vitest is not supported.
What about cypress
I'm a simple man, if it's new I install it
That gif... lol!!
Does Vitest work with React Native?
Vitest works in nestjs?
cool
The main audience here seems to be developers of frontend apps using Vite. I get the appeal of not wanting to double-configure some things, it makes makes sense. But I can't find a reason to want to switch otherwise, maybe I need to be using Typescript (which is just overkill for what I'm working on these days).
Inline tests look nice with the small simple example, but most functions/modules worth testing can quickly end up having hundreds of lines of testing code; I would not want that mixed up with the module itself. Moreover, I wouldn't want to sometimes do inline tests and sometimes not as that is confusing. Also, it looks and feels super hacky to set up this feature with the "define import.vitest = undefined" stuff. I get why it works, but if the configuration on Vitest is so good, why do I have to do something hacky like this at all for such an obvious use-case? Kind of makes me lose confidence with what else might be hiding in the configs.
I'm not convinced to switch, I'd rather deal with the rather minimal jest configuration (Vitest doesn't seem to spare me much work at all) than get another opinionated mess from the Vue team. This feels like the Vue team trying to rope developers in more and more to a Vue ecosystem just for the sake of being in that ecosystem without adding much value. They are a hard working team that has helped push some things in the field forward, but for my preferences, they have also consistently picked poor and confusing abstractions that have caused me more headaches than problems solved, why would I want to switch if I'm not using Vite?
Can the next video be visualizing tigergraph data in vue *hint hint nudge nudge wink wink*
Jest is awful happy to see replacements!
Unfortunately it's not for mobile users
Sadly vitest is much slower then jest and this issue is still not solved after a year
Does that mean that it doesn't work for plain javascript? only typescript?
It just shows that it's also supported in typescript.
Since TS is a superset of JS, everything on JS will work on TS.
Also, you can simply choose JS during configuration.
We need an AI-generated test suite that just automates the whole process.
Video named Why Vitest Is Better Than Jest yet not a single reason to use it besides a single controversial feature
not in angular
If vitest is the same API as jest, it doesn't really solve the issue with jest's convoluted mocking system which makes it a pain to spy on default function exports. I get that it's faster, but it doesn't look like the jest killer that we need.
"Why Vitest is Better than Jest", links to a Jest video, and says the API is built on top of Jest. Catchy titles much?
My god jest is horrible and ruined my Stripe interview😮💨