4.3 Generating and Serving a Code Coverage Report
In the previous video, we output a code coverage report to our terminal window. This was extremely useful, but it can be even more useful to output your tests as an HTML page.
In this video, we will get our app to generate an HTML-formatted code coverage report.
1.Introduction3 lessons, 07:24
2.Scaffolding a Testable Angular App5 lessons, 46:23
3.Testing Angular Applications5 lessons, 51:44
4.Code Coverage With Istanbul3 lessons, 18:01
5.End-to-End Testing With Protractor4 lessons, 23:27
6.Adding Finishing Touches4 lessons, 23:06
7.Conclusion1 lesson, 04:05
4.3 Generating and Serving a Code Coverage Report
Welcome back, ladies and gentlemen. In the last video, we implemented text coverage of our code. And if you're anything like me, seeing the computer automatically verify how much of your code was covered by tests, well it brought a little tear to my eye seeing how efficiently and awesomely we're automating the testing of our website. Using tools like Karma literally a team of one can build a better website than a team of a 100. And a team of 100 using Karma well they can build stuff we can't even imagine today. So we've added a simple text reporter for our coverage, which is excellent. However we're also going to want to add another reporter to give us a more interactive view. Plus we will learn a little bit about Istanbul and karma along the way. The first thing we need to do is, you'll recall Karma uses reporters, we have to add another kind of reporter for html. Let's go to our karma.conf.js file. Here in the reporter block, you'll notice that reporters is an array. That means we can pass a lot of reporters. Let's pass another reporter and we'll make this first for good measure. We'll make the type equal to html But unlike text, this requires more configuration. We're going to be putting all the files into a directory so we need to specify where should you generate these html templates. This is going to be so cool. It's going to be awesome. So we'll specify a directory and we'll say in our test folder, we'll just add a new directory called coverage, where this sort of information should be maintained. As a side note, you're probably going to want to add coverage to your gitignore file, since this is typically not the kind of stuff that will be checked into your gitrepo, along with your business logic. Finally, let's just specify a subdirectory argument. We'll just pass in a dot, which basically means no subdirectory. This will prevent Istanbul from placing our test files in folders named after the browser we're testing. For example, phantomjs 18.104.22.168, this is not a terribly useful folder if you plan to automate these reporters in some other way. So that's pretty rad. Let's see if anything happens if we run our gulp test browser. What's this? Let's navigate back to our text editor and what has appeared inside the text directory? It's a coverage directory. As we open it up we see it's a very, it's a fully fledged html directory with a bunch of stuff in it. It's kind of hard to figure out what that stuff is, if we're just looking at these generated files. Is there a way we can roll creating our coverage and serving it into one step. There certainly is. So finally let's go to our gulp file. We've been able to serve-test and serve the app, so why can't we serve our coverage? Well, we can. Let's just go ahead and copy this whole serve-test block. Our serve-coverage block is going to be very, very similar. Let's paste this in and we'll rename it to serve coverage. Let's give it a different port, let's make it equal to port 7777. And the base directory we only want to serve one directory test/coverage. And there's no need for bauer_components so we can get rid of that. One more thing, though if we just run this, it will, as we expect, serve our coverage folder, but it's not going to actually generate our test first. So let's make the serve-coverage task dependent on the test-browser's task. There is one more thing to be done. Inside test browser, notice we have this function done here. We need to call done when karma's finished. So as a second argument to karma start, passing a function And we'll have that function, simply call, done. Now Karma will run, complete, and then serve coverage will kick into action. Let's give it a shot. Here we have our code coverage report for our app. In this case, there's only one file, but this could be very much longer if there were more files. It's showing us pretty much the same thing we saw in our text, but in a really cool reusable and visual format. Just imagine you're building this massive website, you're the lead director of technology for that website and you're working on it. And, your boss the business leader comes in, and they say to you. I'm kind of worried about this website. Is it reliable? You just sort of laugh, you smile, you invite them to sit next to you. You open up your code cover, let me show you these measurements generated five seconds ago by my automated code cover tester. It's telling you this code base is 99% covered and the remaining 1%, well there's already an issue for that on jira, we're going to get that solved. So by implementing code coverage metrics earlier, you can maintain them and they'll grow with your app. This concludes the section on test coverage. You're now able to serve your coverage in Karma and in the browser, that is super rad. In the next series of tutorials we're going to learn about the very complicated, but very powerful, end-to-end testing using protractor.