Setup React Testing Library & Vitest

[00:00:00]
>> Last section buckle up, it's the hardest one yet. I'm just kidding TypeScript was definitely the hardest one yet. Maybe Redux. I don't know if that one's kinda up to you. It's not this one though. [LAUGH] All right, we're gonna talk about testing and I'm gonna tell you why I'm a really good person to learn testing from is cuz I don't like testing.

[00:00:22]
[LAUGH] I don't like testing. So I try and make my tests really good and I try and write as few of them as possible so that I can maintain them as well as I can. My least favorite thing in the entire world is flaky tests. If something fails, it damn well better to be telling me something or it shouldn't have failed.

[00:00:44]
But I hate tests that waste my time. So I'm going to tell you my testing methodology was like, let's write a small core set of very good tests that tell me something. I'm infamous at one of my companies previously for just going in and deleting all the fake flaky tests.

[00:01:05]
And like, you can't do that. I was like, I'm definitely going to do that. So here we are. Let's talk about vitest. Every version of this course previously, I think has used jest. And Jest and vitest are really similar. The reason why today we're gonna use vitest as opposed to Jest all previous to this is that vitest is made to go with vite, right?

[00:01:32]
It's made by the same people. And the nice thing about vitest is that it reads from your vite configuration. In other words, we do not have to reconfigure anything. Vite is just our vitest it's just gonna work out of the box for us. That seems pretty compelling to me me personally if I'm going to be using vite I'll be using vitest as well.

[00:01:53]
And vitest is meant to be a drop in replacement for Jest. So they're meant to be API compatible which means if you get through this course and you don't like vite and you wanna go back to Jest and parcel. Or Jest and webpage or something like that, everything I'm about to teach you applies to jest as well.

[00:02:12]
Or Jasmine for that matter. Because Jasmine or J is based on Jasmine and vitest is based on Jest. And I think that the translative property applies here that therefore vitest is based on Jasmine. And I mean none of the testings are different. So, this all relatively, works together.

[00:02:36]
If you really do wanna use Jest, just go check out V4 of this course. I use Jest in the last version. A fun side note is that Jest used to be a Facebook product, right? They made Jest to test react applications. And now just it's actually officially an open JS project.

[00:02:56]
So it's no longer a Facebook project. It's actually a full-on open source community governed kind of project, which makes me like Jest all the more. Okay, so we're on a brand new copy of Adopt Me on the 14-context. And we're gonna be using vitest. So I want you to come in and say mpm install-D vitest@0.24.3.

[00:03:32]
And then @testing-library /react@13.4.0. It's worth mentioning that vitest is made by the same people that make vite, I think it's probably in the name that you probably guessed that, but they are. And vite and vitest were made for view initially, right? But they work just as well for react so I have no problems endorsing vitests is a perfectly good way of doing react testing.

[00:04:06]
Does talk a second about testing-library. Testing-library was meant to replace something called enzyme. If you've been writing react long enough, or if you've taken this class previously, you've used enzyme. That was made by Airbnb as like a bunch of testing helpers for testing react projects. It's a huge pain in the butt and I'm very glad that it's gone.

[00:04:29]
[LAUGH] Thank you to all the people that made it. It was better than nothing, which is what we had before. The testing-library is basically better in every single way. It's less flaky. It's easier to use. It's faster, all the good things. Testing-library. It's a bunch of helper functions for testing react applications.

[00:04:50]
You do not us vitest, or sorry, you do not use enzyme with testing-library, they are mutually exclusive. One more thing, I need you to install mpm install-D happy-DOM. I'm gonna do happy-DOM at 7.6.0. Many of you probably have heard of JS DOM. It's like a node implementation of the DOM.

[00:05:18]
We can use it to test browser things without ever having to spin up a browser which is very slow. If you wanna do that you can use something like playwright or puppeteer to do that. Totally valid what happy DOM is is like a minimalistic version of JS DOM.

[00:05:33]
So we don't have to spin up a browser we can just test everything inside of node. My advice for you is for most things, use happy DOM. It's small and fast. It's not a total complete DOM like JS DOM is, but it is much faster. So if happy DOM works, use happy DOM.

[00:05:51]
If it doesn't, then use JS DOM. And then as far as like puppeteer and playwright, my suggestion to you about like those full featured browser environments. Is had like, a few important tests that you run inside of those. And then, that's it. Those end-to-end tests are expensive, their flaky.

[00:06:10]
And so make sure that you're testing really important things don't just go willy-nilly on the end testing. That's just my methodology testing. Coming from someone that does not like to write tests. If you like writing tests, then by all means, tell me the heck off. Okay, so test we're gonna write a function here called test, and it's gonna run some vitest for us.

[00:06:34]
We don't have to be any more specific than that. That is it. Fun little trick now you can write mpm run tests, right? Or mpm run t or if you're extra lazy like me mpm t will run mpm test for you. Am I in the, I bet you I have to do this again.

[00:06:58]
Now mpm t is gonna say, hey, you don't have any tests. I don't know what to do about that. So that's what you should see. But, yeah, fun fact. Mpm t does mpm run test for you. I use that all the time. Okay, one little thing to add to your vite config.

[00:07:21]
Testing here, right? A little testing. And then we just wanna give an environment of happy DOM. By default it's gonna use JS DOM which is much slower. I like happy DOM it's much faster I like fast test. Therefore, going to generate faster texts. All right, so now we are ready to go.

[00:07:43]
We're ready to officially start writing tests. So we're gonna write a test for pet.jsx. So here's from just high level Brian Hall thinks about testing kind of stuff. Try to test functionality not implementation, which is to say like, don't test that the hook has the correct value in it.

[00:08:09]
Test the user interface is working the way that a user would expect it to. In other words, try and approach your tests like a user approaches your application. If I click a button, I see the thing that I want, those kind of things. Like try and tell user stories through your tests.

[00:08:27]
Not always possible, sometimes you need do to test the implementation details. But like doing things like extensive spying and mocking and things like that. Generally, I don't like because as soon as I want to change the implementation of something to do the same action but a better way, I don't wanna go change on my test to test my new implementation.

[00:08:48]
I don't care if my implementation changes. I care if user stories break. That's probably a better summation of what I'm trying to say. Every UI if I've ever worked on changes all the time, right? We're shipping new headers or changing the colors. We're moving the button. Try not to test the UI.

[00:09:09]
If the UI is changes, it doesn't mean it broke. It just means it changed, right? So I try not to do that. A fun way of fixing bugs when I can't figure out like I'm having a trouble fixing a bug is I'll write a test that fails because of that bug.

[00:09:28]
And then I'll try and fix it, until that tests pass that has the benefit of guaranteeing myself that I fixed the bug and I also get to leave a test behind so that regression doesn't happen again. So that, that's a lot of my tests come from that. You should be deleting tests on a regular basis.

[00:09:46]
You should get into the habit of deleting tests. If you have bad tests, if you have old tests, deleting tests should be something that you think about. And then fix or delete flaky tests. The only flaky test I tolerate is something like puppeteer or something like that or playwright.

[00:10:07]
Where I'm like testing if a user clicks here fills in these forms click submit goes here clicks this fills this in and I'm done testing the entire user flow. It's just flaky. Even the best software, even in the best of times it's a flaky like Selenium kind of environment, it's still worth it.

[00:10:25]
Because testing that your user can log in and pay their bill or something like that. It's worth a flaky test to be able to guarantee yourself that that's gonna happen. Everything else if it's flaky, delete it or fix it. One of the two. Okay, that makes sense? That's my high level, what I think about tests.

[00:10:43]
I think it's pretty reasonable. I've arrived at that over years of like I used to work at a company where they did full TDD, right? You would write all of your tests and then you would write the code to fulfill all of your tests. I think it's unnecessary.

[00:11:00]
I think it's unnecessarily slow and I don't think you get any benefit from it. So, you can disagree with me and you can just be wrong. It's fine. I'm okay with that. I'm joking, for the most part. There's definitely people that would disagree with me on that.