Testing React Applications, v2 Adding Code Coverage Reports

[00:00:00]
>> Kent C. Dodds: So, before JEST entered my life, code coverage was always, it was really important that I always set up code coverage for my staff. But it normally involved installing at least six dependencies and trying to wire them altogether, and configure them in ways that were really annoying. Now that JEST is in my life, that's all it takes.

[00:00:22] Yay, I love you Jest, it's so great. So part of the reason why it's so complicated before, for code coverage, is because we're transpilling our code. And so the tools at the time were not able to figure out how to get my non-transpiled code covered. Now it just kind of takes care of all that stuff for me and it's just magic so I run MPMT now with a dash dash coverage and it will give me a report of coverage.

[00:00:54] So that's kind of nice. And I can open the coverage folder that I created so that appeared right here, coverage. And instead of that, it's alcov report, index Html, pop that open. And here we go, that's our coverage report. Looks like autoscaling test, test we never actually run componented update, so we should probably run some more tests for that.

[00:01:21]
>> Kent C. Dodds: So this is kinda fun. The calculator definitely needs some work.
>> Kent C. Dodds: And that all just comes for free. Now there is one problem here and that is we are reporting coverage for our test files. And that kind of changes what the coverage report means, the overall coverage number.

[00:01:44] So this is actually, because our overall coverage is low, the test files are actually bringing our overall coverage report higher than we think that it is. Or than it should be. Because it's like you're tests aren't what you're trying to measure coverage for. So add in including those in the coverage report, not something you want.

[00:02:09] And by default the test files themselves will not be included, but yeah, we don't want our supporting test files to include it either. So we can fix this in our jest configuration with, hold on a second, with the property, collect coverage from and this will be an array of where we want.

[00:02:38] It's a white list of files that we want to collect coverage from and for us we can do anything that matches this glob, anything inside the source JS, and then we can run MPMT.
>> Kent C. Dodds: And now it's only the stuff that's in the source directory. But it still is excluding our tests.

[00:03:02] There's a blacklist version of this as well, and by default that includes your tests.
>> Kent C. Dodds: Cool, so one other thing about coverage, we do not have great coverage today. And that's probably, especially if you're just getting started in writing your test for your app, it's probably gonna be really, really low.

[00:03:26] And you don't really want your coverage to dip below a certain point, especially when you're bringing tests into an existing application with a team of developers, you wanna make sure that it doesn't ever dip lower. It can stay the same, if you're gonna add code, just test it while you add it.

[00:03:42] And then the coverage will stay the same, but I don't want it to go any lower. And so we can make sure that happens by adding a coverageThreshold.
>> Kent C. Dodds: And this is actually a very versatile option, you can specify thresholds for specific files or groups of files, like it's pretty, pretty cool.

[00:04:03] So if there is a section of the after like, this should never ever ever break. So you are like 100% code coverage in here or something like 95% co coverage always in this section of the app or for this file because it's really complicated, something like that. For us and most of the times I just do global and this will just apply to these numbers at the top.

[00:04:27] Overall, together what should those numbers be like? And so when I'm setting up code coverage, I look at, or setting up this threshold, I look at what the current numbers are and I do 2% lower than that. Just to give us a little bit of wiggle room as we're getting started with that.

[00:04:46] So, I'll say statements is, let's see, 18, and branches, wait is it? Goodness, now I forgot if it's branches or branch. Branches, like pretty sure it's branches, is 10 and see, this is. I need to see it lined up. Functions is 19, and lines is 18. So, it doesn't have to be totally perfect, exact, but.

[00:05:20] Cool, so everything's working. Let's see what happens if, lets say we set branches to 13 and then someone bumped it down to 12. Made some changes, added some branches, and now this script will actually fail. So it would fail in CI and it'd say hey you have your coverage threshold set to 13% but it's actually at 12 so add some more tests for cover those branches.

[00:05:48] So we're talking about this statements, branches, functions line, so let me just show you really quick in this coverage report what those different things are. So right here, this is considered a branch, and it's also a statement. So this line is a statement itself, and this is the consequent.

[00:06:11] Here's maybe a better example. You've got your if statement, this is the consequent, this is the alternate. Neither one of those branches is covered and so you get 0% for that branch. Well you get 0% for this branch and 0% for that one, it's two branches. And then each one of these is a also a statement.

[00:06:28] This is a function, so we're not getting coverage for the function. As you can see, the highlighting isn't perfect, and that's a poor request waiting to happen.