This course has been updated! We now recommend you take the Angular 9 Fundamentals course.

Check out a free preview of the full Component-Based Architecture in AngularJS 1.x and ES6 course:
The "Testing Components" Lesson is part of the full, Component-Based Architecture in AngularJS 1.x and ES6 course featured in this preview video. Here's what you'd learn in this lesson:

Before getting into the exercise, Scott dives into how to unit test components. Because the application is modular, each component can be tested without loading the full application. The tools Scott will be using are Karma, Mocha, and Chai.

Get Unlimited Access Now

Transcript from the "Testing Components" Lesson

>> [MUSIC]

>> Scott Moss: All right, so now we got to the part that nobody wants to do but everybody wants to talk about, is testing. Nobody wants to do it, but they all, yeah I test, we test, we got good tests. You know our coverage is, you know 5%.
>> Students: [LAUGH]

>> Scott Moss: Mm, okay. So we're gonna write some tests because a component's not a component without a test, right? Yeah, you are like yeah right, well we'll do that. So let's go ahead and check out step four.
>> Scott Moss: This one's actually really cool. Testing is kind of boring but I actually enjoy testing with this set up.

[00:00:52] It's really cool, in my opinion.
>> Scott Moss: So before we talk about it, let's just talk about tests in general with this stuff. So testing components. So we're gonna be creating, so the fact that we decided to make everything a module and I think I've repeating this all day but I just like it.

[00:01:13] Is that, when it comes to testing this is great, you're gonna see just how great this is. In fact, I think when you start writing the test, I think the only thing in Angular that you have that you might wanna write a test for is the module itself.

[00:01:26] Everything else can be tested outside of Angular, cuz it doesn't need to be. If you look at the way you wrote our files, right, if you go look at blog.controller.js, do you see anything with Angular in here? It's just regular JavaScript, right. We're can just test this as regular JavaScript.

[00:01:45] If it start having to have things injected into it, that's cool. We can mark that stuff out, or we can put the real thing in there, it dosen't matter. But we don't have to tell Angular about it. We don't have to hey, Angular can you give me that controller that I told you about already.

[00:01:59] You don't have to, it's gonna test this thing right here. Or you might have to if you start doing like, end-to-end tests and you will for sure have to do that, but unit testing, no. Don't have to, this is the benefit of it because, I'll be honest testing my Angular is not easy, it is not easy.

[00:02:15] If you don't know the digests very well and you start messing asynchronous things, you can forget about it. You're not gonna be able to test well, and you just won't test it at all. So because we made those models and made that decision, testing is gonna be so easy and so legit and you also get to be able to be like really stringent about the things you test.

[00:02:36] I was telling you earlier, you can test your HTML now. You'll be able to run your HTML through a regex, and you're gonna be like, uh-huh, I'm just gonna check to make sure you put a VM in front of all these. That's crazy but it's legit, cuz now, people really can't change anything.

[00:02:52] And it's like, I just wanna make sure that you actually used this word right here. I want to make sure I use posts, right? And you can test all that stuff, whereas before, you could have done it before, but it would be really, really hard to do that stuff.

[00:03:03] Use jquery to fetch this file, then you gotta wait, it's just like. No, this stuff happens immediately. So that's really cool that we made that decision. So now we can test the individual modules without loading the entire application as well. So, we don't have to load up Angular app, we can just load up blog, and it's totally fine because it works just by itself.

[00:03:26] So, for us to be testing we're going to use a combination of tools, because we're gonna also be running our test in ES2015. We're not gonna write our test in ES5. Nobody wants to do that, we're using ES2015 now. So we wanna write our test in ES2015 as well, and it requires an additional set up.

[00:03:44] So we're gonna need webpack for this as well. So the tools we're gonna be using are karma, mocha and chai. Only because this is my standard setup. I use other stuff too, but this is mostly what I like, karma no brainer. Mocha, some people use jasmine. I like chai so I use mocha, I like my own search and library.

[00:04:05] So like with our source code, webpack will create like a bundled file of all our tests. So we have bundle.js with all our source code. It's gonna do the exact same thing for all of our test files, it's gonna bundle it and gonna give it to whatever karma tells it to go to, which in our case will be Chrome.

[00:04:22] Does anybody know how karma works? No, anybody use karma? So, karma is not a tests framework, mocha's the thing that's testing it. Karma is not a browser either, it's just this bridge between your test runner which is mocha, and your terminal and some browsers. And what it does is it will take your code and whatever thing you're using, in this case mocha, send it to a browser whatever one you choose or whatever browsers you choose, Chrome, Phantomjs, whatever.

[00:04:55] And it will test it in the browser and send the results back to your terminal via websockets. That's what it does. So the other alternative is that you have to write like HTML inside and run it in the browser yourself. This thing will run it in the browser for you and report the results on a terminal with proper exit codes and stuff like that, in real time.

[00:05:15] So it's pretty dope. Google bought them out. They used to be called Testacular and now they are called karma for obvious reasons.
>> Students: [LAUGH]
>> Scott Moss: So our other code will be bundled and tested through karma and stuff. So this is why we're doing a lot of repeat code as far as like third party modules like ui-router.

[00:05:37] So again because we're gonna be importing these models individually, we need to make sure that they register their own dependencies like ui-router. So we go import blog into a test and we mark blog out and Angular runs it, and it's like, I don't know what state provider is, it's because we didn't put ui-router in blog, and it still worked because app had ui-router in it.

[00:05:57] So it worked because we loaded up app, but now we're not loading up app, we're only loading up blog. So now it needs to know about ui-router. So that's where that redundancy comes in, but it's very, very helpful in my opinion. So, if we have some code that was created out of angular, like our controls and stuff, again like I said, we can just test it, completely separate it, it's really awesome.

[00:06:20] So yeah we also did a great job of like isolating everything, and now we can go deeper in to all cool stuff and have much more assertions that we could ES5. Thank you Jen. Yeah. So things like running a template through regedit stuff like I said, are super fancy and super easy.