What’s Up With Vitest?

CSD. Oh, welcome to Syntax. On this Monday, hasty treat, we're gonna be talking all about v test, it. Which is a new testing I guess you could call it a test runner or a test framework for JavaScript applications.

It's really, really cool, and we'll be telling knew all about what it is and why it sparked so much attention on this year's state of JS survey. My name is Scott Zelensky. I'm a developer in Denver, Colorado. And with me, As always, it's Wes Boss. What's up, everybody? Stoked to be here. A little bit of a cold today, so apologies for that. I was gonna ask about that. It sounded a little coldy.

Yeah. Yeah. I just getting over.

I don't know what it it's that, like, 5 thousandth time in in, last years that you think you have COVID, but it's just a cold, you know?

Yeah. I've managed to not get COVID yet. And, you know, really, every time you get Really super sick. I got, like, really sick a couple weeks ago, and I was just like, well, I guess this is it. This was the this was the last time. This is like COVID. That is it. Do you guys still have the, mask mandate there in Colorado? They they're just dropping it here in Ontario. It's just about dropped everywhere. So, like, There are some places where they'll expect you to wear a mask still. Still, obviously, like, the hospitals or, you know, doctor's appointment stuff, but, it. Yeah. Our kids don't have to wear them at school. We're now back to our, like, normal day care process of how we drop the kids off, and just showing up places without masks feels Feel weird. Yeah. Wow. Yeah. I don't know what it's gonna feel like. I'm I'm just used to moving my mouth in weird ways underneath my mask when I'm at stores. Oh, yeah. And my Glasses don't stay on when I wear a mask. So it's like what I'm psyched about is I can move my head without my glasses falling into the street, which has happened a 100 times.

Man. That's funny. I, I was I have I always have, like, masks in my pocket, and we had, like, a huge bonfire the other day. And for the next, like, week, I had this mask in my pocket that smelled like campfire. And I was like, why didn't this is like a business opportunity,

masks that smell like campfire. It's amazing. Every time I put on them, my wife and I are, like, sharing masks occasionally in the car, and it's, like, you put on 1 and it's, like, Filled with foundation.

Oh, yeah. Yes. Smells like perfume. Some makeup. Yep.

Oh, what a crazy time. Well, let's let's get into it. I guess we we should, hit up our sponsors first. 1st one is Sentry.

2nd 1 is Magic Valley. You wanna tell us a little bit about Sentry there, Scott? Yes. Sentry is the perfect place to see all of your errors and exceptions happen, a perfect place to track application performance To make sure that your users are generally having a good experience on your site. This is a service that both Wes and I have used Since long before they sponsored us, but let me tell you, it's one that I I check just about every single day all the time. I make sure that Anything that is, severe, anything that I have to be aware of, anything that's causing a crash, I make sure that is 100% on my radar before I have to it. Users emailing me about something not working. Now the cool thing is is that you can go ahead and mark something as being attached to a specific release it. And then fix that, and then watch as it is marked as fixed. There's a lot of new features that come all the time in the century, and I'm loving some of this new stuff.

It. Just like you can now create your own dashboards, things like that. So head on over to century.i0.

Use the coupon code tasty treat, all lowercase, all one word, and you'll get a 2 months for free. Thank you so much for Century for sponsoring. We are also sponsored by [email protected].

They are the notification inbox for your product. So, it. You know, you go to a website or you go to an app, and you've got that little bell in the corner. And you click it, and you can see all your notifications. And those notifications are Often synced to your email, and there's push notifications on your phone.

And that logic is really, really tricky to implement into your application. So Magic Bell is an entire API that you can integrate into your application that gives you a The entire suite of notification, you can allow your users to, to fine tune it. Okay. I don't want push notifications, but I do wanna email and, it. All kinds of really great access over that. They have a REST API. They have a GraphQL API. They have wrappers for all, many popular, libraries, Node. Js in the browser, React React package, iOS, Android, you name it. It's awesome. We want you to check it out us. Atmagicbell.com.

Use the coupon code syntax f m. That's gonna get you 10% off your 1st 12 months.

Thank you so much, Magic Bell, for sponsoring.

Alright. Let's get on into it. So v test. I I was gonna call it v test, but, what is it? What is it? Scott, give us the rundown, and then we'll dig into it a little bit more. Yeah. It's is is I think it is probably v test.

Vite test is basically a new testing runner.

They don't call that a test runner. That's just what just called it before.

And, basically, this thing allows you to run tests in a way that is both modern and very fast. So we had the the state of JavaScript, survey episodes a couple little why is it go couple weeks ago, and people were, really responding well to v test on that survey. So Me, personally, I said, okay. This thing's supposed to be fast. It's supposed to be a modern replacement for Jest, and it is, You know, very favorably seen by the people who used it. Now it's time to give it a try.

So I I threw it into my code base the other We we had a Veeet config already in our code base, so it's nice and easy.

So, basically, what this thing is is Vtest is a modern test runner that utilizes things like ESM, so that it it is not using common JS. There's less There's less caught up there in the transpilation of things that can load up your files as modules really easily, but it also utilizes, it, behind the scenes, and it runs very, very quickly. So you can use the same Vite config File that you use for your application for your tests. And I don't know about you, Wes, but I've always had, like, a lot of kind of separate infrastructure for my test that felt very much like I'm testing the tests themselves to have this thing work, and I'm not entirely confident that whatever Babel set up I have to get just happy is Transpiling my code in the same way that my production bundles are. You know? Yeah. That's always a little bit scary where

the setup Environment for your test is a little bit different than ad actually runs on your your end users because it's like,

Could something be different? It just feels like what's the point. So, basically, this thing utilizes a Vite config.

It's fast, And it utilizes Vite. It also uses this NodeVite thing to run essentially Vite for a node application, which I actually gave a try to my, platform, my API just for fun, and it's pretty cool to to try out in general.

So what makes V test special beyond the fact that it's fast and modern? It. Out of the box, TypeScript and JSX support, meaning you don't have to do any bit of configuration whatsoever to get those things supported, it. Which is great because, writing tests in TypeScript is is actually a lot of fun compared to writing tests without TypeScript.

So having that out of the box just work without having to set up any sort of special TS config or anything like that, that was such a giant pain in the butt with Jest For me, personally so the the fact that it just works with your standard v config file is really great.

Another thing is that it's a it's like HMR for tests is what they say, where, basically, I don't know how many people have have worked in it. A test environment that doesn't feel a lot of fast very fast to work in. So you save a test, and then you watch as all of your tests update in, you know, either in parallel or it. Sequence. Right? Well, this allows you to only rerun essentially the test that has been changed or or the test for the code that has been changed. So Vtest knows the graph of your modules, and it makes it able to smartly rerun only the related tests that you need to have.

Meaning that you can keep this thing running all the time to much much greater success.

You know, when I when I Code in a test driven development way or I code with my tests. I always feel very annoyed when I save something and then have to wait for all of the tests to complete it. Or your your the feedback loop to me isn't tight enough. So this really, like, tightens up that feedback loop. That with Jess, though, it Jess will only rerun tests that are against files that have changed because it hooks in your git repo,

And it it's smart enough to know that, isn't it? Honestly, I have no idea,

the way that that could work because personally,

it. Our tests were TypeScript, and there's compilation steps involved and things like that. Oh, so you had, like, a bit of a in between there, and it wasn't able to It wasn't enough. It wasn't tight enough, so that maybe it had to rerun everything for you. That's a pain in the butt. In my experience, this is still

much faster, running the same tests.

And and by all means, you can basically run the same tests because there is the standard try for built in assertions or just expect compatible APIs.

So your tests are going to work basically the exact same. Small caveat. You you'll need to import things rather than just having a bunch of globals available out of the box. It. You can set up the globals the same way you would ingest. But out of the box, there is no there's no globals. You'd have to import it. So it's fast. It's instant.

It connects the stuff you know and use TypeScript JSX, ESM support.

There's workers multithreading via tiny pool. Not something that I've used myself, but it's, good for performance.

Filtering time out, concurrent for test suite so you can filter only run specific tests, kind of stuff you'd expect from a testing framework.

Another thing is it's compatible with just snapshots.

So if you are a snapshot Tester, you like to use your snapshots. You already have them loaded up. You can use the same snapshots in Vtest without having to have anything extra.

Mocking is built in via Tiny Spy.

So mocking, for those of you who don't test very often, is basically where you need to, Fake something. Right? Maybe you have a module that hits an API. You wanna fake that API call so you're not doing that API call on every test. That's really nice. Yeah. So mocking built in.

Now there's also happy dom or j s dom for dom mocking.

Have you seen Happy Dom before? This was something that I hadn't really seen.

I haven't seen Happy Dom directly. I was using one called, CS DOM. Forget that. No. It's I I had an issue with JS DOM running in Cloudflare Workers a couple weeks ago, and I went to another one Which was able to run because it only used a worker API, which was really nice. So, No. I haven't specifically seen Happy DOM, but it's sort of like a JS DOM alternative. It's a bit quicker. Yeah. Yeah. And it seems like it's quite a bit quicker where it says performance,

it. Parse HTML for JS DOM is 256 milliseconds, and happy DOM is 26 milliseconds.

So we're dealing in really small bits of time here, but it is apparently faster. I haven't used this yet. I've just been using the defaults, which I actually don't know. I'm I'm not doing any DOM testing with v test right now. I'm just doing straight up node testing. So I haven't gotten too much into this, but, hey, it looks nice. Just also looking at the the API here, and it looks like if you have

a Jest setup, you'd be able to move over it pretty easily, I think, because, like like you said, it's the exact same API.

Whether you're doing simple things like to be is Equal to or, they also have snapshot testing, all the different assertions that are in there.

What about, like, Testing library. Like, does that does that work with this, or does that replace that? Because generally, with with Jest, You you just use Jest, and then you use something else like an enzyme or a test library or something like that to actually, mount your components and and test them. Does does that do that as well, or you still reach for,

something else? I would imagine that it, you can use testing library. No problem with this Yeah. Just because of the nature of that library. Right? You're just importing something. You're it. Mounting it. You're rendering it, and then you're checking it with the the Dom stuff. So, I mean, in that regard, it shouldn't function any differently than just. That said, there is listed in the features, component testing baked into this thing. So component testing for Vue, React, Lit, Svelte.

You know what? I haven't I haven't used it yet, and I'm not quite sure exactly how it works.

But apparently, according to this, you can do component testing from Vitebsk.

And based on the way they have that listed as a feature, it would lead me to believe that you would not need Those other libraries that said, the the docs on this aspect of it, it's funny if you go to the guide, then you go to the features, and you say, I I wanna learn about component testing, and it it's kinda just like a placeholder there in the docs. So this thing is still fresh enough where the docs are still waiting for that bit of information as far as I could tell, But it's a it's listed as a feature, which leads me to believe that you wouldn't need to use that. That said yeah. I don't I don't know. I've mostly been doing node with this. It. There's also baked in code coverage, which if you've never used code coverage, it just tells you basically where, your application is it. Light on tests. What needs testing? What doesn't need testing? What is, you know, what percentage of your code has coverage within tests, essentially? And that's baked in via something called C8, which I'd assume is a code coverage library.

Now there's also One of the most interesting features in this and maybe one of the most far out features in this thing is that there's in file testing.

So Those of you who have used Rust before will know that you can test your Rust functions directly in the same file as the function itself, therefore, kind of collocating your test with the code itself. And you can do that exact same thing within Vtest.

Now people on on YouTube were quick to say, wait a second. Isn't that gonna, you know, bloat your source? And the answer is that there's a plug in to remove all of that stuff from your source.

So it seems like it's pretty easy to have that be code split out. No problem. But this would allow you You essentially have a function, and then just below it, say, expect this or this. It should do this. And that way, you're it. Kind of keeping all your stuff together.

And if you were to write your function and then as tests below it, that to me is a really interesting work flow and something that I had actually really enjoyed within Rust when I was doing Rust briefly.

So I I is fully well knowing that a lot of people are going to really cringe at the thought of having your test collocated with your code, your function code.

But I would say this is something that you maybe give a try to because it feels nice in practice. Yeah. That's that's really cool. You're right. Your CSS,

Your logic, your temp planning, and your tests Yeah. On the same file? Yeah. Right. Obviously, not everything needs to be done that, but it. It might work. Like like, we kind of do that already in some cases where you put your test in the same folder. Right? Like, why not throw it in the same file? Yeah. Another thing that I did, Wes, that recently, you can there's a new feature in Versus Code where you can, like, have some files act as folders.

Have you seen that that feature? Files act as folders. No. Yeah. It's does that work? It's a new feature, and, basically, you give it a glob pattern to say, like, I want if if I have a dot test dot ts file, I want that file to be hidden in the Explorer behind the file of the same name.

And then, therefore, you don't have a bunch of test files cluttering up your folder structure when you're looking at it. It. I also did the same thing for all of my config files so that, like, you have your Prettier RC, all those things, your ESLint, all of that stuff kind of gets scooped up into its own fake folder. So that way, when I'm looking in my explorer view in Versus Code, that it's not, It's not taking up a ton of space. I I think I think that's a pretty neat approach to hiding some of those test files that can feel very, it. Just very overwhelming sometimes in your code base. I'm just looking at,

the examples here on Vitess, And they have an example with React Testing Library. So, it would make sense that you use it with React Testing Library because Or sorry. Not React testing. I I should just say testing library. Right? Because it it works with literally anything.

And I'm just looking at the docs here. They don't I have much information about the DOM stuff that you mentioned yet. Mhmm. But I imagine, so testing library works on JS DOM. And and what testing library does is it. Just renders it out to a fake DOM, and then testing library gives you a whole bunch of, handy API calls instead of you having to be, like, a crew selector all dot text content equals 7.

You can say, to have text content seven. You know? Like, you can it gives you a whole bunch of, like, niceties that sit on top of, of your your existing vanilla JavaScript API. So It makes sense in that v test can run happy DOM or j s DOM, and then all of the, you can use testing library on top of that to get the nice API. So makes sense. It it this is this is very clear to me what this is. You know? It's a environment that will mount your components and run your tests, and then it gives you a set of extra things on top to say, it. Expect it to be 6 or whatever. But if you want some additional, API methods that makes more sense in whatever a language you're working in or whatever framework you're working in, then you can add on testing library or whatever you need. So that's pretty nifty.

I like this a lot. Yeah. Yeah. Me me too. Personally, I I like stuff that leaves out the configuration when You already have a configuration. You know, I already have a a Vite configuration.

I already have this stuff set up. I don't wanna have to set up a whole another structure for testing it. My code to compile the test to be happy to get just to be happy with the code.

Like, this is not like, this is not massively Disruptive.

This is basically just like this is kind of what you're doing already, but it works it works a lot better.

So, if it's just Take the hard parts out of it Yep. And just keep going on with your life. That's what it seems to be like for me. So, man, this is great. I may have to Switch over to this. Yeah. In in my experience, just from trying it out as a long time Jest user, I've I've been using Jest for it. Anything from UI component testing in the past, but now mostly just node testing,

I gotta say that it is really easy to get up and running, especially when you have a it. Test suite of just tests. I I I really had a an easy time getting going with this thing. I had one issue where it was Unhappy with the temporal polyfill that I had in, but, I think that's been resolved by now. So yeah. Really cool stuff. V test, v I s t e s t dot dev. Give it a try. Give it a check, especially if you're already using Jest. I think you'll be pretty shocked at how much faster this thing is. It's just just

2022 is the year for, like, it's a year for tooling, I think, in speed. Like, we figured out These frameworks compile and run very quickly.

And now all these smart people are going for other stuff, testing back and Things like that. That's pretty exciting.

Yeah. It's very exciting.

This is this is gonna be great. I think a lot of people are gonna pick this up this year And really, really have a good time. So check it out at v test dot dev, and we will see you on Wednesday.

Peace. It.

Peace. Head on over to syntax.fm for a full archive of all of our shows, And don't forget to subscribe in your podcast player or drop a review if you like this show.