This course has been updated! We now recommend you take the Complete Intro to React, v8 course.
Transcript from the "Test Coverage with NYC" Lesson
[00:00:00]
>> [MUSIC]
[00:00:04]
>> Brian Holt: Now we're gonna test coverage, which is kind of an interesting metric. I think people rely on it too heavily. But I also think it is, it's interesting to look at nonetheless. Chasing a 100% test coverage is foolish, if you wanna ask my opinion. No one did, but that's what I think.
[00:00:23] And luckily we don't actually have to really write any code for this, we can just go ahead and just figure out the bash command and it just automatically works with our tests. The basic idea of test coverage is it's gonna show you how much of your code is actually getting covered by unit test.
[00:00:38] So basically if I run this test, am I missing blocks of code, am I missing code paths. And we can actually visually show you this with this tool called NYC.. Most of us are probably, if you've done anything with test coverage are used to using Istanbul, right. That's the most common one with JavaScript.
[00:00:56] We're gonna use NYC, which actually wraps Istanbul, and I think it's just a little bit easier to use. You can achieve this with Istanbul just fine. So at this point, if you don't have NYC installed, just say npn install -g nyc. What we're gonna do here is nyc -- reporter=lcov --reporter= text -- reporter=html.
[00:01:34] Basically saying give me all of the reports you can possibly generate. That's what all these mean. Then I wanna say --require babel-register. At this point we are saying like, you're gonna run into ES6 when you're running my tests, so just be aware of that. And then you're gonna say --extension.jsx.
[00:02:01] So that's saying also look at all my jsx files. And then the last thing you're gonna say is you're gonna give it the command to actually run your tests. So in this particular case, it's gonna be npm test. Kind of a long command, hopefully it works.
>> Brian Holt: So it's gonna run your test first and then it's gonna give you a basically a code coverage report.
[00:02:29] So we were good children and we actually covered all of the code paths in search and show card. Which is kind of cool. This basically means that all of the code in search and show card got covered by our tests, right. Everything ran at least once, which is not to say there's no bugs in your code, it just means that at least for the test case that you're running, your code got covered and you got an expected result back.
[00:02:56] So let's go make it so like part of it's not covered. So let's go to search.jsx and just put like another random function here. So random function.
>> Brian Holt: Okay, and this is gonna be console.log or something like that, right. It's just like another function here, right. And now nothing's calling this, it's never getting run anywhere but it exists in our code, right?
[00:03:31] So save that and come back and run your command again.
>> Brian Holt: And what you'll see here is that now we don't have a 100% coverage now. And we have uncovered lines, it's gonna tell you which lines did not get covered by this. So this is actually can be even more interesting.
[00:03:56] So now if you look at ls -lsa, you have a hidden folder here called NYC output. Nope not output, I want coverage. So you have a folder now called coverage. If you CD in the coverage. It has like a bunch of interesting reports you can look at but the most interesting here if you say open index.html, it's actually gives you like a nice visual representation of what your coverage looks like.
[00:04:22] You can actually go look in and see, this is the code that never got ran. So you can actually visually see the code that's not getting covered by your tests. I think that's a pretty compelling read, that's actually a pretty cool feature of Istanbul and I think it's a fairly recent change as well.
[00:04:41]
>> Speaker 2: Can you show us how you got there again?
>> Brian Holt: Sure. So, I'm in my repo, right? I went to coverage, there's a command in OSX. I don't think it exists in Windows or I don't know about Linux at all. It's just called open, that says please open this with the host OS, and you just open index.html.
[00:05:10] If you're using iTerm 2 like I am, you can also Cmd+Click which is kind of a fun thing. Cmd+Click index. And that's actually gonna open Sublime but whatever. The other thing you can do is you can just come to your browser and say File > Open. And then navigate there, right, so coverage index.html.
[00:05:39] That works too. Yep. And the nice thing about like. We got this really nice pretty looking report for essentially zero work, right? We just had to install the tool and just have it run our tests, which I think is also pretty compelling. I like getting things for free.
[00:06:01]
>> Brian Holt: So any questions about this? Cool, not cool. Sit down, you're stupid and whatever. You can be nice about it though. Okay, so let's just take this entire mess and put it into our package.json because that is an absolute terror to have to type every single time. So go to your package.json and you can call it cover or coverage, whatever you wanna call it.
[00:06:31] I call it cover
>> Brian Holt: And now you can just do npm run cover and it'll tell you.
>> Speaker 3: Somebody in chat had problems with command not found for nyc. So did I actually.
>> Brian Holt: Did you install it globally?
>> Speaker 3: No.
>> Brian Holt: No. That might help. [LAUGH] If you're run it from MPM though, right.
[00:07:02] So if you put this in your MPM, and then you say MPM run cover it will work for sure, because there's a local copy, and MPM is smart enough to find it.
>> Brian Holt: So yeah, if you're having problems in not finding it, just put this in your MPM package.json and then just do mpm.
[00:07:26] So I will prove my assertion. I will uninstall nyc.
>> Brian Holt: So now if I type nyc, it doesn't work, right? But I can still do mpm run cover and it will still work.
>> Brian Holt: So that works as well.
>> Brian Holt: Okay.
>> Brian Holt: So I'm gonna go take that fluff code out of here now.
[00:08:06] So, because we don't need it.