Webpack 2 Deep Dive Exercise: Initializing Karma

Transcript from the "Exercise: Initializing Karma" Lesson

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Speaker 1: There was a quick question.
>> Kent C Dodds: Sure yeah.
>> Speaker 1: Can this be used with Angular 1 apps?
>> Kent C Dodds: Yes it can. The problem with that you'll find with an Angular 1 app is, often the state of the application lives throughout of the code base, like it's everywhere. And so like when I say okay you can have a model open with the form filled out.

[00:00:27] Well if the recompiling the template is going to clear out that form then that's not like super useful, it's almost like refreshing the page or even recompiling the template will likely clear out the modal as well, like it'll get rid of the model. So yeah, like I said at the beginning, lots of the features that I'm talking about with WebPack are put well to some applications and not as much to others.

[00:00:56] And so yeah, this is one where like everybody really loves to talk about hot Mocha replacement and it is really really cool. But it's like your application has to be in a certain way for it to really be hugely beneficial. That's been my findings anyway. So I don't know if you get a whole lot of bank for your buck on at Angular 1 app with how much you're learning.

[00:01:22] I know that people do it. There are people in the world who have done that.
>> Kent C Dodds: Okay, any other questions? So, yeah testing, testing is something that is really important. I am curious, how many people here have like 50% code coverage on their applications?
>> [INAUDIBLE]
>> Kent C Dodds: Yeah.

[00:01:49] Anybody with a hundred? Okay, good. [LAUGH] You're wasting your time if you do one hundred percent code coverage, unit test code coverage on the 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 source it's a lot easier, smaller modules, it's a lot easier to get 100%.

[00:02:13] Yes.
>> Speaker 3: Do you have any thoughts on line coverage verses branch coverage?
>> Kent C Dodds: Yeah. Line coverage basically, it's like this line executed. That's all line coverage tells you. Branch coverage says, this if statements alternate did not execute or this turnery like the turnery operator was always false when you ran this code or whatever.

[00:02:39] I am under the impression that I like to see as many lines of code run that are important that they never break. So, like whether or not it's lines of code or like a branch of, like whether or not an if statement is run. I more care about like, if this broke how better would that be?

[00:02:57] And that's why I try to focus my efforts is where it'd be bad. Good question. Other questions? Okay, sweet. So, yeah we'll probably, lots of this is just like setting up the stuffs. So I'm mostly gonna show you the code for these. So, here we pretty much, right here we're installing a couple dependencies karma-chrome-launcher and Mocha I don't know how many people here use karma?

[00:03:28] Okay, so it's pretty ubiquitous to all, I'll just briefly explain it. Karma is basically responsible for running tests. So if you use Jasmine or Mocha they both have a CLA that will run your test for you. But if you wanna run in an actual browser they actually, I'm pretty sure they both have the ability to run it like, for you to put script tags in an HTML and then you can open that index HTML in a browser and stuff.

[00:03:55] But that's like kind of tedious to have to refresh that and whatever. And so, karma makes it really easy to load all of your like specify what files you want to have loaded into a browser and run those for you. It has like a watch mode so it would refresh the browser for you and refresh your files and then you can also run across multiple browsers as well.

[00:04:15] So we're just using Chrome but you could have, there's a Firefox launcher and a Safari launcher and Internet Explorer launcher and who knows maybe a Brave launcher, I don't know. But yeah, so karma, that's karma's responsibility. It's loading files into a browser and running and opening that browser for you, yeah.

[00:04:34]
>> Speaker 1: Question, why not Eva? Is that all you can [INAUDIBLE].
>> Kent C Dodds: All right so, Eva testing framework. It does not work in the browser, it works just in node. And I like it a lot. It's great, it's got a really fantastic API. And it only has a like a node CLI, so you have to, like if you wanna test stuff that is using the DOM you have to use like a DOM implementation like JS DOM.

[00:05:01] I'm using it in my project at work right now and I love its API. One of the things that Eva promises is performance, because node is single threaded. If you're running your mocha tests, you're only running that on a single core. You have like eight, 1200 cores in your machine, you're only using one of them.

[00:05:19] And so what? What Eva says, okay we'll spawn a different process for every single test file that you have and run the test in those processes. Those who send us back the results and then we'll aggregate them for you in one thread. So, I have found that there's is a lot of overhead with spawning those processes and it actually results in pretty dead slow performance.

[00:05:42] So, I am currently working on migrating from Eva to Mocha again, so which is really sad. I really like Eva a lot it's API is really amazing but it's just too soft, yeah.
>> Speaker 1: Just a general question what about Headless Chrome?
>> Kent C Dodds: Yes, Headless Chrome is also something coming up.

[00:06:01] 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 a head full chrome I guess it's like 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.

[00:06:20] There are also headless browsers, probably the most common is PhantomJS. Anybody know PhantomJS? Okay, so this ones really popular because setting up Chrome or Firefox on a CI server, where you're running your test continues 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.

[00:06:44] You don't need to have like a window pop up or anything, it just kind of is running node as a separate process, it's pretty awesome. The problem with Phantom is until, I'm pretty sure that you 2.0 has been released and there's been an update. But until recently it supported ES3 which like we're all excited about is ES 2016, 2017.

[00:07:07] Yeah, it supported to ES3 not even to ES5 so you had to poly 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 2.0 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.

[00:07:30] 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 of 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, [LAUGH] hopefully it's useful information.

[00:07:48] Okay so then we're also installing karma-mocha and that gives us all the mocha Global's 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 have to Project 2 have a couple scripts that will use karma-start.

[00:08:10] And also a watch mode that uses the test script, and forwards along a couple arguments, so that you can have the tests run as you're developing. So if you're a fan of TDD, that's what you're gonna wanna do. I am a fan of TDD. And then you run the update of the validate script to also run our tests, because that makes sense.

[00:08:32] Okay, so then we also have this, well I'll just show this, also we have a src/controller.test.js file. So how many people here have a test directory that mirrors their source directory? So all that, yeah okay, so this is pretty common. You have like src/controller.js, you're gonna have a test/controller.js and as your file system grows, both of those grow and supposedly they're supposed to mirror each other.

[00:09:06] So if you move controller than you're supposed to like in the source directory then you supposed to move the controller in the test directory. This doesn't scale very well and I'm not gonna like belabor you with my explanation cuz I have a blog post about it. Ask me about it later.

[00:09:20] It's what code comments can teach us about scaling code basis? I think that's what it's called. So you can look it up later. But-
>> Speaker 1: You're asking but what's that switch no single run on line 46.
>> Kent C Dodds: Yeah so, that? To be perfectly honest, I'm not entirely sure why it needs both of these.

[00:09:41] To me it seems like it would make more sense to just have like a --watch, but that's what you need to be able to get watch mode running for karma.
>> Kent C Dodds: Yeah, so anyway you'll find that the test file is in line or right next to the controller.js file and you can ask me later about why I co-locate those things, but it's a good thing.

[00:10:07] But then finally you also have your karma config, I'm not gonna, 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 cuz we're gonna be making changes to that.

[00:10:26] Okay, so still, right from here we don't actually have, well we do have actually tests running but we don't have WebPack integrated, the test that will have running is this a test that does nothing. It's just using the mocha API. Yeah, so I don't think it's super valuable for you guys to or for you all to work on that right now.

[00:10:51] So, any other questions before I move onto the next extremely short explanation, okay. Cool, so the next thing that we do is we just are adding our assertion library probably just on this 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 the expect global in the browser.

[00:11:18] Then we're just expecting true to be true and high to equal high. So just to verify that we have our tests all set up and running. Any questions about that? Okay.