Transcript from the "Jest Setup" Lesson
>> We're gonna to start from a fresh copy of our route repo here. We are going to write some unit tests. So let me give you my full bias on unit tests. As opposed to other people, I really don't like writing unit tests. It's like my least favorite part of my job.
[00:00:16] I don't know if maybe other people like it. I don't quite like it. So I only try and write unit tests that I actually believe in. That, I think are going to benefit me that give me in confidence, that when I check in my code, that I'm confident that I'm not gonna break stuff.
[00:00:33] So in other words, I think 100% test coverage is a fable fairy tale that's not worth chasing because a lot of times you write garbage tests. Just to make sure you cover that one last line, right? And I don't believe in that garbage one last test, right? I will not write that one last test.
[00:00:50] I fight with people all the time about this at LinkedIn, all the time. I'm going to try and teach you to write effective unit tests that you believe in. That inspire confidence in your code. And I'm gonna try to teach you to not write tests that are a waste of time.
[00:01:05] That's my goal here. I would rather have a few rock solid confidence inspiring test than many crappy tests that cover everything. That's my gist here. All right, so we're gonna test with jest. I've used jest for basically like six years now. I used to when it was terrible before they released like the the revamped version of it.
[00:01:30] And I use it now and which is revamped and very nice. So, what I want you to do is I want you to say npminstall-D jest. @26.6.3 and then @testing library/react @11.2.5. So Jest is also released by Facebook, it's not the same team at Facebook. Not necessarily and they're not tied together.
[00:02:22] So if you need help with like the various inner workings of like how the matches work. All that stuff is coming from Jasmine. Jest does not choose to re implement that. They just reuse Jasmine and Jasmine is a great testing framework. You can also use Mocha and Sinon and Chai.
[00:02:39] And those are great testing frameworks as well, we're just gonna stick to Jest today. We're gonna be using Testing Library React. This was formerly called React Testing Library. But now they have a testing library for Svelte and View and for Angular. So they have various different flavors of that now.
[00:02:58] Previously in this course I used enzyme instead of testing library. That used to be like the State of the Union. That's what Airbnb uses. But now everyone's moving to testing Library React. Even the React docs recommended. So just use this, believe me it's a lot better than Enzyme.
[00:03:17] So let's start writing some tests. I'm gonna show you several varieties of tests of things that I think I would write. First things first, create a new directory inside of your source directory called _ _Tests_ _. Why all the underscores? This is a double underscore, also known as a dunder, and I did not make that up.
[00:03:39] It sounds ridiculous, but that's what the python community calls it. So what double underscores mean? It means that it's magical. And I'm not making that up either. It means that the name is actually important. It must be called underscore, underscore test underscore underscore. So if you're looking at python code and you see a lot of dunders.
[00:03:55] That's why the double underscores means, this is a special name, it must be called this or it will not work. In other words, jest is going to look for your tests inside of the underscore underscore test directory. That's why we're calling it that. In fact, you can see that my logo changed here from the VS code, icons, extension.
[00:04:16] Okay, we're gonna put all of our tests in here. You don't necessarily have to do this with jest. But it will pick up things automatically if you do and I like automatic things. So I'm gonna do that. Okay, we also need our babel to work. So go ahead and open your babelrc.
[00:04:33] Because your code is gonna be run, its browser code but being run in node. We have to give it some special kind of tuning here. So let's go ahead and take a look at what that would look like. This is our babelrc. This all looks fine to me, but the one thing we have to do is we have to add one more thing under here says called env.
[00:04:55] Which is to apply different sorts of transformations depending on what environment we're in. So if we're inside of the test environment, which jest will automatically put you in the test environment. Then what we're gonna do is we're gonna have presets. Okay? And it's gonna look relatively similar. We're gonna have @babel/preset or press preset env.
[00:05:30] Then we have to get that an object of targets. That's another object, and the inside of that is node current. Basically what we're saying here. And if this is really hard to copy because of all of the indentation. One, yes, it is. Two, just copy that in my notes.
[00:05:54] It's in the, Right here. Testing. I think we're in basic React. No, we're in the one previous to that. We're in Intro React Testing. Just copy this beast right there. But know the reason why we're doing this is so that when we're in the testing, so when note m equals test.
[00:06:18] Target node don't target the browser because my tests run in node. That's what that means. Make sense? All right, and then I want you to go to your package.json really quick. We're gonna add two different commands here. One is gonna be test. And that's gonna be jest, surprise surprise.
[00:06:46] And another one is going to be test:watch. So I'm gonna show you a fun feature of just called watch. Which means we can run our test interactively. All right, now we can start writing some tests. So, some general rules of thumb. Try not to test implementation details, right?
[00:07:14] Don't test.state one from state a to state b, right? Don't test that your hook went from green to blue. Test that the button changed from green to blue. So, approach all of your testing from a user perspective. What is happening to the user? What is the user seeing?
[00:07:31] What is the user doing? Don't test it from the developers perspective of what is my state look like? Did my redux change? Don't test those details, try and test what's actually happening. Another thing is that UI has changed so frequently I try not to test UIs in general, right?
[00:07:50] Like I try not to test that the brand is showing up, right? Because the brand might change class names it might change something else about it, right? There's a million ways to test your code. Let's try and keep it to a bare minimum of things that are actually important to us.
[00:08:06] In general, when I encounter a bug I first try and write a test that would have caught that bug. And then I try and make that test pass, right? So, I try and make a test that fails first on the bug that I have and then I work to make that test pass.
[00:08:20] So two things, it makes my debugging go faster because then I have confidence of when I fixed it. Two, I'm kind of guaranteeing that I'm not gonna regress in the same way again. Because if I caught a bug and it's been assigned to me and I have to go fix it it's bad enough that I don't wanna waste time on it in the future.
[00:08:38] Not always true, these are all kind of guidelines, not rules. But those are some things I try and adhere to. And then the last thing, just ask yourself what's important about your app? Is the login process important? Probably write a lot of tests about that. Is the copyright showing up in the footer correctly?
[00:08:57] Is that important? Maybe not. Maybe don't test that, right? That's why I'm saying you don't need 100% test coverage because no one cares about that. That's kind of my methodology of testing anyway, of like ask yourself what's important tests that. Ask yourself what like, if there's a bug here, is it gonna cripple me?
[00:09:15] Maybe write less tests or no tests about that and then just react to those. One of the worst things in the entire world just anecdotally, the one of the worst things in the entire world is having a large test suite that you have no confidence in. Because if it fails, and you're just like, it's just being finicky again, I'm gonna ignore it.
[00:09:35] Not only now slows you down, and like it doesn't do anything for you. I would much rather have no test than bad tests. So, I'm just crushed about this kind of stuff. So I apologize if I'm rubbing anyone the wrong way. But I've worked on some really bad test suites before.
[00:09:58] One of them was just so many Selenium, tests that just nothing. But I couldn't check it in until the Selenium test passed. So I would have something that would be working. I have to run it like five times. I'd be there like, Friday at like 8PM trying to go home.
[00:10:13] It's like just pass. I know this works. I watched it work. And it was just it was like no don't know. I don't, it's windy over here. So no, I'm not gonna pass your test this time.