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 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.
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'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.
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?
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”.
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) )
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.
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
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.
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?
Sorry man, I generally love your videos, but apart from inline testing, which I would generally prefer to avoid, you can do exactly the same as you did with vitest, with just Jest...
I mean the thumbnail speaks for the video, anyway if someone is telling you, without nuance, that the established solution is bad and the new shinny stuff is good based on a hello world example that's probably irrelevant. But that's the JS Community/RU-vid's need for new content that demand that kind of stuff.
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.
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.
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 !
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 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.
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?
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?
