Kent gives a quick overview of Karma which is the testing framework he’ll be using in the Todo application. Kent then walks through the exercise which initializes and configures Karma for use in the application. The solution to this exercise is located on the FEM/02.0-init-karma branch.
(dubstep music) - [Student] There was a quick question. - Oh sure, yeah. - [Student] Can this be used with Angular 1 apps? - Yes, it can. The problem that you'll find with an Angular 1 app is often the state of the application lives throughout all of the code base, like it's everywhere. And so, when I say, "Okay, you can have a module open "with the formed filled out", well, if recompiling the template is going to clear out that form, then it's not super useful.
It's almost like refreshing the page. Or even recompiling the template will likely clear out the module as well. It'll get rid of the module. So yeah, like I said at the beginning, lots of the features that I'm talking about with Webpack are applicable to certain applications and not as much to others. And so, this is one where everybody really loves to talk about hot module replacement, and it is really, really, really cool.
But your application has to be in a certain way for it to be really be hugely beneficial. That's been my findings anyway. So I don't know if you'd get a whole lot of bang for your buck on an Angular 1 app with hot modules reloading. I know that people do it, and there are people in the world who have done that. Okay, any other questions? Sweet, so... Yeah, testing... Testing is something that is really important.
I'm curious how many people here have like 50% code coverage on their applications? Yeah! Anybody with 100? Okay, good. (laughing) You're wasting your time. If you do 100% code coverage, unit test coverage, on an application. But, 50% is pretty good. I generally like to stick around 70% code coverage on applications. And 100% on open source. That's because open search it's a lot easier.
Smaller modules it's a lot easier to get 100%. Yes? - [Student] Do you have any thoughts on line coverage versus branch coverage? - Line coverage basically it's like this line executed. That's all line coverage tells you. Branch coverage says, "This if statement is alternate, "did not execute" or this ternary, the ternary operator was always false when you ran this code or whatever. I'm under the impression that I like to see as many lines of code run that are important that they never break.
So, whether or not lines of code or a branch, whether or not an if statement is run, I more care about if this broke, how bad would that be? And that's where I try to focus my efforts. It's where it'd be bad. Good question. Other questions? Okay, sweet. Lots of this is just like setting up stuff, so I'm mostly going to show you the code for these.
So here we pretty much, right here, we're installing a couple dependencies: karma, karma chrome launcher, karma mocha, and mocha. Again, how many people here use Karma? Okay, so it's a pretty ubiquitous tool. I'll just briefly explain it. Karma is basically responsible for running tests. So, if you use Jasmine or Mocha, they both have a CLI that will run your tests for you, but if you want to run in an actual browser, they actually, I'm pretty sure they both have the ability to run..
For you to put script tags in a HTML, and then you can open that index HTML in a browser and stuff. That's kind of tedious to have to refresh that and whatever. And so Karma makes it really easy to load all of your, specify what files you want to have loaded into a browser, and run those for you. It has watch modes, so it'll refresh your browser for you and refresh your files. And then you across multiple browsers as well, so we're just using Chrome, but there's a Firefox launcher, and a Safari launcher, and an Internet Explorer launcher, and who knows, maybe a Brave launcher, I don't know.
That's Karma's responsibility, is loading files into a browser, and running and opening a browser for you. Yeah? - [Student] Question. Why not AVA? - Yeah okay so AVA is a testing framework. It does not work in the browser, it just works in Node, and I like it a lot. It's great. It's got a really fantastic API. And it only has a Node CLI, so if you want to test stuff that is using the DOM, you have to DOM implementation like JS DOM.
I'm using it in my project at work right now and I love it's API. One of the things that AVA promises is performance because Node is single-threaded. If you're running your Mocha test, you're only running that on a single core. You have like 8-12 hundred cores in your machine and you're only using one of them. And so what AVA says, "Okay, we'll spawn a different process "for every single test file that you have "and run the test in those processes. "Those will send us back the results "and then we'll aggregate them for you in one thread".
So I have found there is a lot of overhead with spawning those processes, and it actually results in pretty dead, slow performance. So, I am currently working on migrating from AVA to Mocha again so which is really sad. I really like AVA a lot; its API is amazing, but it's just too slow. Yeah? - [Student] Just for a general question, what about Headless Chrome? - Yes, Headless Chrome is also something coming up. I don't think that there's a launcher, but just to kind of explain Headless Chrome.
So, what you're looking at right now is like a headfull Chrome, I guess. There's a UI associated with it, so I've got buttons, and I can interact with the page here, so it pops open a window. There are also headless browsers, probably the most common is PhantomJS. Anybody know PhantomJS? Okay so this one's really popular because setting up Chrome or Firefox on a CI server, where you're running your tests, continuous integration server, can be a real pain in the rear.
So, you use PhantomJS, which is a headless browser which basically you just install it. You don't need to have a window pop up or anything. It just kind of is running in Node as a separate process. It's pretty awesome. The problem with Phantom is until I'm pretty sure that two dot oh has been released, and there's been an update, but until recently, it supported the ES3 which we're all excited about ES 2016 2017. Yeah, it supported ES3, not even ES5.
So you had probably fill the Dickens and it was just a real pain. So I haven't used Phantom for a really long time. I'm pretty sure that two dot oh supports ES5 now, but yeah. So Headless Chrome though is coming, I'm pretty sure in Canary right now. You can get a Headless Chrome, but I don't think I looked around for a Karma Headless Chrome launcher and I don't think that exists yet. So if any you all want to build it, that'd be awesome. I'd love it. Good questions. Other questions? Okay, sweet. Am I talking too much? Okay, hopefully it's useful information.
Okay so then we're also installing Karma Mocha, and that gives us all of the Mocha globals and make sure that Mocha is installed in our project. You may love that, you may hate that. But yeah, then we have the Mocha testing framework. I updated the project to have a couple scripts that we'll use come or start and also a watch mode that uses the test script and forwards along a couple arguments so that you can have the test run as you're developing.
So if you're a fan of TDD, that's what you're going to want to do. I am a fan of TDD. And then you run the updated validate script to also run our test because that makes sense. Okay so then we also have this. Well here I'll just show this also we have a source controller test JS file. So how many people here have a test directory that mirrors their source directory? So like all of the, yeah okay so this is pretty common.
You have source slash controller dot js, you're going to have a test slash controller dot js, and as your file system grows, like both of those grow. And supposedly they're supposed to mirror each other, so if you move controller, then you're supposed to like in the source directory, then you're supposed to move controller in the test directory. This doesn't scale very well and I'm not going to beleaguer you with my explanation because I have a blog post about it. Ask me about it later. It's what code comments can teach us about scaling code bases. I think that's what's called.
So you can look it up later, but yeah. - [Student] You're asking, but what's that switch null single run? - [Student] On line 46. - Oh yeah so that, to be perfectly honest I'm not entirely sure why it needs both of these, to me it seems like it would make more sense to have a dash dash watch, but that's what you need to be able to get watch mode range for Karma. Yeah so anyway, you'll find that the test file is in line or right next to the controller dot js file and you can ask me later about why I co-locate those things, but it's a good thing.
But then finally you also have your Karma config. I'm not going to like... Karma is an important tool, but it's not the tool that we're talking about today. And so you can look at that later. The most important part that you need to care about are the files that we have here because we're going to be making changes to that. Okay so still... from here we don't actually have. Well, we do have actually tests running, but we don't have Webpack integrated. The test that we'll have running is this test that does nothing.
It's just using the Mocha API. Yeah so I don't think it's super valuable for you guys or for you all to work on that right now. So any other questions before I move on to the next extremely short explanation? No, okay. Cool. So the next thing that we do is we just are adding our search and library. Probably should have just done this at the same time, but we're using Chai in this project. Adding that as our dependency, adding Karma Chai to get some to get it to expect global in the browser.
Then we're just expecting true to be true and hi to equal hi, so just to verify that we have our tests all set up and running. Any questions about that? Okay.
Note: This course was created by Frontend Masters. It was originally released on 8/8/2016. We're pleased to host this training in our library.
- Initializing webpack
- Development vs. production environments
- Debugging webpack
- Loading CSS
- Testing with webpack
- Coverage basics
- webpack optimizations
- Tree shaking
- Code splitting