Transcript from the "Snapshots, Watch Mode & Test Coverage" Lesson
>> Brian Holt: We're gonna do one more test, which is the hairiest one of them all.
>> Brian Holt: And we're gonna say expect, where is that, container.firstChild toMatchInlineSnapshot.
>> Brian Holt: That's it. So, what a snapshot is, is it's going to go render this entire thing out. And the first time it runs it, it's just going to dump all the markup in there.
[00:00:38] And then it's gonna say, I assume every time after this, it's going to match, right? So if I say npm run test, it's gonna say one new snapshot's written. And you can go in here and you can see, this is what it looks like given that input, right?
[00:01:03] So if I go into details, for example. Or not details, let's look at SearchParams.
>> Brian Holt: And I change the markup just a little bit. Let's say this is location, cuz maybe they're not living there, I dunno. And I run this again, it'll fail the test, right? Because now it's diverged, right.
[00:01:27] It's gonna say, hey, you said that this was gonna match, and now it says question mark. Like, I don't know what to do with this, right? So this is what I would call a low-confidence test. It's low-effort, low-confidence, but it's also free, right? I just match the snapshot, and now I can see, if I change something over here and the snapshot's breaking over there, that's a problem, right?
[00:01:53] But let's say I intended to put those question marks there. All I have to do is say, oops, terminal, npm run test and then I just put -- --update. Which basically means I'm saying jest --update. So this -- means pass this on to jest, right? So if I run that this way, or it's not, sorry, it's not that.
[00:02:24] It's -u. It's gonna say, you meant to do that? Okay, I'm going to update my snapshot. And so now, if we go back in here, to my search params, if I put location, right? Now you see it's written in there. Which is cool. So I would just say put that in your package.json as well.
[00:02:51] So you have test. I would put another line that's test:update and put -u in there. And we're gonna show you two more, test watch, which is jest --watch. And test:coverage, which is going to be,
>> Brian Holt: jest --coverage. So jest --coverage.
>> Brian Holt: Okay, so I showed you what update is.
[00:03:27] If you do npm run test watch now, it's gonna go into an interactive mode that's gonna see, everytime that you save your code, it's going to rerun your tests, right? And then it's going to only rerun tests that are failing. So I'm just gonna click a, and it's gonna run all my tests, and it's gonna say, everything's fine.
[00:03:45] And so, it puts it into this interactive mode so that you can fix tests on the fly. It's really quite nice. So you can say only change ones that have done something like that. Or if I go into SearchParams right now, SearchParams, and say location, and I change this now.
[00:04:05] And make it fail. It'll run that test again because it sees that this one's changed. It's like, this one failed, right?
>> Brian Holt: And so it puts it into this interactive mode, which is really cool.
>> Brian Holt: Last thing I wanna show you, let's just put this back the way it was so it passes again.
>> Brian Holt: There, it passed. So last thing I want to show you here, if I do npm run tests:coverage, this is going to run istanbul on your project, if you know what that is, which is a test coverage tool. So, now let's just make this maybe a little bit bigger.
[00:04:48] Gives me a nice graph, it's like, okay, your pet component has 100% of statements covered, it has 50% of branches, 100% of functions and 100% of lines covered. So it's saying, hey, you're missing this one though, right? So it lets you know how much of your code base is actually covered by test coverage.
[00:05:07] Now, we can actually go one further than this. It generated this lcov directory, or no, coverage directory. So cd coverage. And then if you go into the lcov directory, which I don't know what that really stands for, but, lcov-report. And then I say open index.html. This is gonna open this in my browser, and it's gonna give me a nice little dashboard of all this stuff.
[00:05:29] So I can actually click in to use drop down, and see, I missed these lines, right. This never gets run, right? But I can see this part right here. This got run 19 times. So it's real good to go, right? So this gives me like a nice dashboard.
[00:05:45] And I can see, I have other files here that are not covered at all, for example. So again, I don't really like using test coverage too much as a metric of code quality. I think it's like measuring a house by how many nails you put into it, which is odd.
[00:06:01] But okay, sure, right. It's maybe indicative, but definitely not like causative, right. So I think if you have 100% test coverage, you're writing too many tests. Just my opinion.
>> Brian Holt: Cool. Any questions about tests that I showed you? This is not exhaustive. This is just kind of your first foray into it.
[00:06:24] And if you want to learn more, go watch Kent's course.
>> Brian Holt: Any other questions in general? That's the end of intermediate React.