Transcript from the "Setup Jest & Testing Library" Lesson
>> So today we're gonna be learning to test with Jest. I'm fine if you don't like Jest. There's a lot of people out there that have very strong opinions on testing frameworks, and I am not one of them. I use Jest because I have used Jest. That sounds like a weak reason, it's because it is a weak reason.
[00:00:16] [LAUGH] But I've used Moca, I've never used other professionally but people that use it seem to quite like it I've never used no tape or no tap or any of those. But again all of them seem to work fairly well. Jest has more batteries included that it kinda does a lot of the things for you.
[00:00:34] It's also put out by the Facebook team themselves. So that means that it's frequently used with React. But again, I really don't have a strong opinion on the matter. It is helpful to know that Jest is built on top of Jasmine. So if you have questions about the specific testing helpers and all that kinda stuff, or if you wanna use a library that augments Jasmine generally it will just work with Jest out of the box.
[00:01:03] So you can think of just as the framework around Jasmine. Okay, so we have our product here, we ran node module or npm install to get our node modules and we're going to install Jest. So we're going to npm install dash capital D, and we're going to do Jest at 27.5.1.
[00:01:30] And we're gonna install @email@example.com Okay, so Jest is a testing framework, and then you need like some specific like helpers to work with React. We used to use a thing called enzyme and previous versions of this course I taught enzyme. It was a library put up by Airbnb to make it easier to test React.
[00:02:03] And it was way better than what was available before. But then the open source community came out with testing library, which ended up being even more useful. So we're gonna use that. And in general, people don't use enzyme anymore. So if you do happen to a company that is using enzyme, my suggestion to you is try and get them on testing library.
[00:02:22] It's just way easier to work with. Okay, that gets us starting here. Testing libraries/react used to be called react dash testing dash library. They just renamed it because now there's like testing library dash angular testing library dash svelte. They make all of those helpers now. Okay, so inside of your source directory I want you to create a new directory called underscore underscore tests underscore underscore.
[00:03:23] Something special will happen if you name it this, so in other words please do not rename this, right? Or else you're gonna break something. So in this particular case everything in underscore test, Jest is gonna assume everything that lives in that live, in that directory is a test.
[00:03:39] So it will run everything in there. It will also, if you make something called model.test.JS, it will also assume because you put the dot test dot JS in there that that's a test, but it's very contingent on you naming it something that Jest can find. I'm fine with either way.
[00:03:59] I tend to do this underscore under square test. Cause I like all my tests to live together. But you can disagree with that and I'm fine with that. Cool, we do need to set up Babel to run on our tests, right? Because we're gonna be trying to run React and JSX in a Node environment.
[00:04:19] Right, so we have to set up so that Babel knows how to do that. So I want you to pop into your Babel RC here. And what we're gonna do here is we're gonna put in nth. This is gonna run specific Babel rules whenever node F is equal to test, that's what this is going to do.
[00:04:52] And we're gonna have to tell it for our presets with at Babel l sash preset dash mth. Okay, there's that and then another one here this is gonna be an object. No, sorry, that's what that is. This is also an array, it is. The way you set up a configuration in Babel RCs, it's a lot of curly braces and square brackets.
[00:05:35] Okay, and then we're gonna have to tell it targets. Sorry, this is an object. Targets. Node current. Okay. Now that we've kinda set this up, we also have to tell it what to do in a normal environment as well unfortunately. So, we're gonna have to set this up here as well of presets.
[00:06:20] It's gonna look really similar. It's a comma there. @babble/preset-react, I actually don't think we need to do this. Let's try to see what happens. Something might correct us here but what we'll see. All right, so I think now you do have to say npm install at babble slash preset -mth.
[00:07:01] And you actually should do that with a dash D. So let me fix that really quick, npm on babble slash preset mth. Okay, so now what we wanna do is we're going to package.JSON. And we're gonna make a test command. And that is going to just be Jest and Jest might have to figure everything else.
[00:07:41] And we'll make one more command here, which is test watch. Because Jest has a really cool function called watch, that we wanna use as well. So a fun fact, npm has a couple shorthands, npm i is one I've been showing you, but if you do npm t, it'll run whatever is in tests.
[00:08:10] So instead of saying npm run tests like this, you can do npm t and that'll run your test command. Okay, so this is what we expect to say is like, hey I could not find any tests that's true we haven't written one so let's go ahead and go and try and write one.
[00:08:31] So, before we get too much into the specific syntax of writing a Jest test for React, let me explain to you my methodology of testing UI code, which is hard won over years of writing a lot of tests and UI code. The worst thing in the world is a bad test.
[00:08:52] It's way worse than having no test in my opinion. Because if you have a bad test, that means you don't trust your tests in general. And when you don't trust your tests, that means when you actually do have a problem, you're not gonna believe your test suite, right?
[00:09:05] You're gonna say, they're just being finicky again. You're gonna ignore it and you actually was catching a problem for you. So in general, I try and write as few tests as possible to that give me as much confidence in my code as possible. And when I have a bad or finicky test, I either need to fix it or delete it.
[00:09:22] And there's like no two ways about that. So I'm kinda a testing minimalist. I try not to test implementation details like I try not to test like internal state of like a code of like if this goes from this hook inside my React code goes from A to B.
[00:09:40] I try not to test stuff like that. I tried to test things which are more like the user clicked this button and expected this thing to happen, right? So it's more told from a user story perspective than a developer story kinda perspective. Every bit of UI that I've ever worked on changes a lot.
[00:09:58] So I really try not to test user interfaces cuz I don't like the thrash of trying to update tests as interfaces change. I instead try and test, can the user log in? Can the user find their name? Can the user change their email, right? These things that a user would care about.
[00:10:16] I try and test things that are important, right? Like, it's maybe it's not important that a user can go from light mode to dark mode or I don't know, something like that. But I'm much more concerned about can a user login. Like things are absolutely critical, I'd rather have five tests covering something important than five tests that cover a bunch of things that aren't in important.
[00:10:39] Which is a different way of me saying, I don't believe in 100% test coverage. I think that's a fool's errand, and I think it's just a vanity metric. Cuz I can give you 100% test coverage with that tell you nothing, or I can give you 10% test coverage that tells you everything.
[00:10:56] I prefer the latter. So I'm just disclaiming my feelings about testing because it's a bit hostile. [LAUGH] And people disagree with me but I'm gonna to teach you that with my personal bias there. So if you disagree with me just take it with a grain of salt that's appropriate.