Component-Based Architecture in AngularJS 1.x and ES6 Testing Q & A

Transcript from the "Testing Q & A" Lesson

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

[00:00:03]
>> Scott Moss: Where we left off yesterday, testing. So specifically wanted to leave off for testing because I was telling Mark yesterday, you don't want to start with testing because then people you set the tone, people will get bored of testing. So you got to end with it. All right, and you give them the option that they want to stick with it or not, because it's the end.

[00:00:22] So I'm glad everybody who stuck around to do the testing did it, because if you didn't go through that you'd probably have a hard time trying to figure out how to test the stuff that you've been learning the entire workshop, which is not fun. I can tell you that.

[00:00:36] So before we move on, were there any questions that might have come up yesterday that you just forgot to ask or didn't get the chance to ask? Anybody have any of those questions before we move on to other stuff?
>> Speaker 2: There was one question online that maybe would really help to clarify so,

[00:00:52]
>> Scott Moss: Yeah.
>> Speaker 2: John M was wondering
>> Speaker 2: Why we needed to have an exclude for node modules in our web pack loader, when we're passing Gulp client as the entry point. So his understanding is that we should just be scanning client for JavaScript files and that we don't necessarily need to exclude node modules.

[00:01:17]
>> Scott Moss: Right, and he's exactly right, half of that. So we are only scanning the client files, but if we go look at the client files, all right. If we go look at the client files,
>> Scott Moss: And we just go look in app.js, the first file that we wrote Boom!

[00:01:38] import angular from 'angular'; that comes from the old modules, right. So yeah, we are scanning the client files, but the client files are imported node modules. So that's why we have to exclude those paths from being used to babble code, any other questions?
>> Speaker 3: That's an awesome explanation, thank you.

[00:01:58]
>> Speaker 4: Mocha verses Chai. Chai is an assertion library, that's what you said?
>> Scott Moss: Yeah, so Mocha is a testing framework and Chai is an assertion library. Because Mocha doesn't have one built in like Jasmine does. So Jasmine and Mocha, the syntax is synonymous, but Jasmine is the full thing.

[00:02:14] It has, it's the testing framework. It has an insertion library built in, it has like mocking capabilities built in. Mocha is just a testing framework, that's it. And Chai is everything else that Mocha didn't have. And there are other ones out there, expect JS and all type of other insertion libraries.

[00:02:32] So I just chose those two. Any other questions?
>> Speaker 5: Yeah, I got a question. When you're gonna test, first off, I don't understand why there is such a stigma around testing. I think it's good thing to do. But when you're testing for directives, let's say, for example, I work on a UI framework that's used in translating.

[00:02:53] And where we recreate a bunch of HTML, like a button for example. Would you test behavior that would be like an Angular directive and you click to make sure that that's passed through to the template or-
>> Scott Moss: Yeah.
>> Speaker 5: You would test?
>> Scott Moss: Yeah, so those type of directories are UI based type of directives that have dom events.

[00:03:24] Yeah, you totally have to test the behavior on those things.
>> Speaker 5: What would you test specifically that Angular, I don't know. Let me rethink the question and I'll ask you later.
>> Scott Moss: Okay, okay, cool.