Vitest UI

[00:00:00]
>> Just a few tasty notes as I kinda begin to get us into the next section. Just in case, you wanna half listen to me while you also type stuff in the terminal, cuz that's great. There's some various options that you can pass to Vitest. If you use an NPM test, you have to do the -- and then the flags to have them pass through, but there are some fun options that you can set.

[00:00:25]
Run will have it not drop into that watch mode, which is useful with some of the different reporters. There's also an HTML reporter and JSON. And other ones, dot is just a lot less on the screen, it's just like little dots that show you that have passed. The other really kind of cool one that I have found myself at first I was like, this is a little bit like kitschy but now I'm into it is if you do --ui, it will spin up an entire like user interface.

[00:00:57]
That shows you entire test suite and will show you what dependencies got pulled in and the code itself and where the failures are. When we talk about the feedback loop, it's great to see it in the terminal. But a lot of times, if you look at my terminal when we go back, I got a lot of room there and some of those errors are big.

[00:01:22]
And so I do have a second monitor when I'm at home, and so having that up there where I can kind of see the tests in real time feedback as I'm hitting save all the time. And having that feedback loop, it makes me way more productive. So actually to I guess answer that question earlier isn't use Vitest over Jest, I don't think has Jest has it, but it's pretty cool.

[00:01:43]
I will show it to you real quick just, npx vitest --ui. And here you can say, it will spit out my variable show me the overall looking at the test. On this case, it'll show me like a visual representation of all of my passing wonderfulness. All the tests pass, you can see a module graph, there's not much to see in this case.

[00:02:05]
Because these are very simple files, you can also just see anything logged to the console. Cuz I don't know about y'all but yes, there's ways to set break points and debug, absolutely. Do you know what I do most of the time? I put a console log in there, and then I scroll up to my terminal looking for it.

[00:02:25]
I put in like, lalalalalala, wow, so I can go command F, find it. This a lot of times is a lot better because I can just see that stuff right here. So big fan, like it a lot, spins up a little server at a ridiculous port number. And let you navigate through all your tests, like kind of rerun them all.

[00:02:42]
It's even got a dark mode if that's your thing. We talked a little bit before about how if your tests pass because they don't fail, right? And one way to handle this particularly, there are certain techniques that make a lot more sense when you're developing the tests, like then when you are actually running them all the time a lot of times.

[00:03:06]
If I'm starting brand new on something right, like some of the first tests that I write, I will delete, right? I will import the thing from the implementation file and write a test that it exists, I don't need that. If any of the other tests pass it probably exists.

[00:03:24]
But there are certain things I'll do in the very beginning to verify that everything works is nobody likes a situation where you've been coding for 45 minutes to find out that you made one fundamental mistake at the beginning, and nothing's been running at all anywhere. So one of the ways you can do this is you can insist that there is at least, some number of assertions that happen in your test file, right?

[00:03:51]
Like be like, hey, I'm expecting a certain number of assertions happen where literally any, right, and then it will blow up if that didn't happen. This is a great way to sanity check, right, because testing is great until you're in that situation where it's not working and your tests are passing, right?

[00:04:08]
That if you're not getting an error message, sometimes, it's very hard to see. So this is an easy way to do a quick sanity check. And I say this, and I call it out specifically because I would love to inspire you to get into the routine of just once or twice when you're writing a new test and it's passing, do a sanity check to make sure that it is in fact, correct.

[00:04:36]
Actually, asserting anything, but whatever's happening is not in some kind of weird conditional, or you're mapping over an empty array and doing an expectation, and that expect is never getting called ever. Don't be like me, I say these from experience.