Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Lessons:25Length:2.9 hours
  • Overview
  • Transcript

4.2 Adding Istanbul to our Application

Welcome to this next video, ladies and gentlemen. In this tutorial video we're gonna actually be implementing Istanbul into our app. It's only gonna take a few minutes. But Daniel, I hear you saying, I though Istanbul was complicated to implement. Why is it only gonna take us a few minutes? Well, I'm glad you asked that. Throughout this entire process of building this app, working together, I have been extra careful to build the app in such a way that we could implement code coverage easily. If we had decided to implement code coverage after the fact, it would have been a hard, hard job. But luckily, since we knew from the very beginning we wanted this, it's going to be very fast and easy to implement. First up, we're gonna have to install some dependencies. So open up your terminal window. So we're gonna install two things. So type npm install --save. And we're going to install Istanbul. And then, separated by a space, karma-coverage. And we'll install those. Karma-Coverage is a tool that plugs Istanbul into Karma. For technical reasons, Karma and Istanbul just work great together. It's very challenging to implement Istanbul without Karma. And very easy to implement Istanbul with karma. Next, we have to make some updates to our karma config file. Let's go to karma.config. Hm. It's been a while since we updated it. Is our karma still going to work? Let's give it a shot. Open up your terminal window. And type gulp test-browser. Hm. We're getting an error. Can't find variable module. Well if you remember, we brought in our Angular-mocks and we included it in our index file when we serve our tasks. But Karma, we kind of have to repeat ourselves and include all the files again. So let's include angular-mocks in our Karma file right along with Angular. That's looking good. Let's try it again. So we gave it a shot, and now our tests are working. Very good, seven out of seven success. We can now move on to implementing coverage. Coverage is complicated, but I'll explain a brief overview of how it works. First, Istanbul goes and looks at your code base and makes note of every line of your code. Then, it hooks in to the test runner that's to follow, and follows the test runner as it's running the code, noting every line of code that was visited. Finally, it turns this raw data into actionable metrics, as in percentages of how much code was covered. So, with that in mind, the first thing we need to do is add some preprocessors. Let's add a preprocessors property to our config. And the name of the property will be the directory, so let's just make it app and throw in all the JavaScript files there. And the second argument is an array of the processors. We'll use the coverage processor which we included just recently. Now, you'll notice I have this extra line here that may not be in your directory, the plugins directory. It's actually an unnecessary line. If you don't include the plugins line, Karma will automatically find every package prefixed with Karma and just use that. I implemented plugins earlier to test the bug, but we really don't need it. So I'm just gonna comment it out. Now, let's give our app a shot. Hm, while we have no error, but we have no coverage reporting. Why is that? Well, we've added a preprocessor, but we have yet to add a coverage reporter configuration. So lets do that. Back in karma.conf under preprocessors, let's add another property and we'll call it coverageReporter. CoverageReporter has a property called include all sources, which we want to be true. This will allow us to test our app without any further configuration. Secondly, we have to specify what reporters we want. This is an array. Consider if you will the following scenario. You're running code coverage in Istanbul. You want to output the date to a dashboard where your QA engineer can see it. At the same time, you want to send your data down to say strong loop our new relic for analysis. The same data format isn't going to work for both of these. You want sort of an HTML page for the first situation, and a JSON object for the second. That's why we can specify multiple reporters. In this video, we're only gonna specify one reporter, but we'll add more later. So let's add an object in the reporter's array. And we'll just say the type of this reporter is text. Well, this is looking pretty good. Let's give it a shot. In my terminal window, I'll run gulp test browser. And we've made a Syntax error. There's now one more thing to do. Remember, we're running our karma configuration through gulp. So we're gonna update our gulp file as well. Let's go to our test browser. And we're going to add a reporters argument to this configuration. And within the reporters, we're going to specify we want two, mocha and coverage. All right. So now, we have both our Karma file and our gulp file covered. Let's run our test browser gulp task. All right, check it out. We are seeing our code coverage. Have a look at this area at the end of our output. Istanbul has given us the following metrics. It's told us that, of our main js file, we only have one js file. We've covered 93.75% of the statements and 93.33% of the lines. We have ourselves a very small app, so this isn't that useful of information. But, if we had hundreds of files, we would know immediately where the problems were. In the finished version of this app that's available on GitHub, there are many more files which have been broken up specifically to show how Istanbul can identify files where code coverage is inadequate. What we're seeing here is the text reporter of Istanbul. In the next video, we're going to implement the far cooler HTML reporter.

Back to the top