Transcript from the "Writing Your First Test" Lesson
>> Brian Holt: Yeah, let's go ahead and create the test first. So now inside of not inside of helpers but inside of test. We're gonna create a new file and I think I call it search, no, app.spec, yeah that's fine. Call it app.spec.js.
>> Brian Holt: Js, thank you,
>> Brian Holt: Okay.
>> Brian Holt: So the reason why I call it js and not jsx which is kind of going against my rule that I told you previously is you don't have to configure Mocha to look for jsx files.
[00:00:50] Or you do have to configure it to look for jsx files if you just call it js it will just find it automatically. I'm all about being lazy. And the reason why I used .spec, that's actually just really force of habit for me. I don't know if anyone's ever done RSpec in Ruby or anything like that.
[00:01:05] It looks for files called spec. I like calling them spec because it's just a very quick way to say, this is the test. So when I'm using my file finder and I'll just look for specs, I can find all of my tests. Works for me, but it doesn't necessarily have to work for you.
[00:01:20] Mocha doesn't care. In some testing frameworks it is important, in Mocha it's not.
>> Speaker 2: I always wondered why we didn't just call them tests. At.test.js. We call them specs because of Ruby or whatever.
>> Brian Holt: The only reason I keep doing it is because I've already always done it that way.
>> Speaker 2: Right, exactly.
>> Brian Holt: It's one of those things. Okay, so instead of app spec js, we're gonna do one of our famous comments, because we don't want to fail lint, right. There's things called ES lint environments. It's a bunch of basically globals that ES lint knows to just ignore, so if I say yes and Mocha just knows this is Mocha testing file.
[00:02:00] I'm just gonna add a bunch of white listed testing type variables into your globals list otherwise you have to do the global it, global described, global bunch of other stuff that Mocha includes, which is fine if you prefer to do it this way. But this is just really easy to remember and now you know if it's future proof if you tend to introduce more tests with more keywords right so up to you.
[00:02:28] Okay. [COUGH] So we're going to bring in here we're going to bring in Chi.
>> Brian Holt: This is our assertion library, which we'll see in just a sec how to use that. And actually, we don't have to do that, we can just do,
>> Brian Holt: expect, cuz that's actually what we want out of Chai.
[00:02:51] We want this expect function. That's going to allow us to basically make assertions of how we want our code to look.
>> Brian Holt: So the first thing when you use here is describe, and this first comment, for those you who are not familiar with Mocha is basically the the thing that you're going to be testing, right.
[00:03:18] So in this particular case we've been testing our search component but here you can put anything. It can be like, if you don't like that you can say this is my search component, right. This is just a future footnote to yourself, so put whatever is descriptive in there for you.
[00:03:37] This is descriptive for me to let me know I'm testing a reactor component called search. Okay and then you get a callback function. Okay and then in here you gonna say it, should pass, then give that a callback function. So basically, here you're describing all of your different tests, right.
[00:04:03] So, here's all the tests that I'm gonna be running against search, so I can have different levels of it, right. So, I can have it, I can have another it, another it, and another it, right, I'm not gonna do that right now, we're just gonna do one test but, you can also do nested describes, this is not meant to be a Mocha test or a Mocha class but just giving you some context if that's interesting to you.
[00:04:25] Okay, and then now we're just gonna write the most basic test in the world we're just gonna say expect, one plus one, triple equal to two, right. We expect that to be true. So you're gonna say I expect this to be true. The nice thing about this is it tries to be as English like as possible right, so I'm expecting everything in here to evaluate to be true.
[00:04:57] If you're interested there's a couple styles of using Chai, there's, I can't remember what they're called, one of them is expect one of them is assert and one of them is should. Is it should? It might be should. Yeah, okay, should.
>> Brian Holt: So you're welcome to use the one that most fits the way you're thinking about your tests.
[00:05:21] To be totally honest my is called power assert which is not in Chai at all. Go check it out and I don't wanna talk about cuz it's actually kind of complicated but it's super cool.
>> Brian Holt: Okay end of tangent. Okay, so let's go and run this test right.
[00:05:37] Like we have one test and we expect our test to pass. So let's go up here and run, go to your command line and we're gonna say Mocha dash dash require. First of all if you don't have Mocha do mpm install -g mocha if you haven't already done that.
>> Brian Holt: So the cool thing about Mocha is if you called the directory test it knows to look in the test directory and find all the js files and just run them for you, which is really nice. I'm gonna put that up top. So I'm gonna say mocha --require test/helpers/setup.js.
[00:06:28] So it's going to basically run that file first and that's gonna run all of your other files, right? So we're gonna create our browser like environment. In this particular case, it doesn't matter since we're not actually testing the browser yet, but go ahead and give that a shot.
[00:06:41] Mocha not found, I need to install it.
>> Brian Holt: Hopefully that's pretty fast.
>> Brian Holt: So actually you don't have to do the dash dash require right now, you can probably just type Mocha and it should work right now.
>> Brian Holt: Okay, clear. Just run Mocha. And something's up. Yeah. No you do have to run it cuz I'm using ES6 stuff.
[00:07:18] So I have to say mocha -- require sorry, --require test/helpers, test/helpers. If you're using the latest node it probably would work. Five seven, five nine, is that what it would be on? Something like that.
>> Speaker 3: A couple of us have errors back here.
>> Brian Holt: Okay.
>> Speaker 3: Babel poly fill, can’t find module, do you just need to install that?
>> Brian Holt: I think I forgot to put that on package requirements. So do mpm install --save--dev, here let me show you. Mpm install --save--dev like that, babel- poly fill. I missed a couple of these requirements, so my bad. [LAUGH] sorry. In fact, I'm gonna do that myself. If you want to know a neat shortcut you can do dash capital D, and that's save dev.
[00:08:22] So mpm install, which you can also just type as mpm i. Then you can do -D babel-polyfill. That's exactly the same thing.
>> Brian Holt: I don't know why I get so hung up on using the shorthand. [LAUGH] It, cuz it's so dumb right, I'm typing like ten more characters right, maybe I'm just burning like one more calorie but whatever.
[00:08:49] Precious calories. Okay clear. So, now try that after you install the poly fill. Plus working cool. If you want to do something kind of fun cuz we all wanna do something fun, I think it's dash R, so just do dash R dash capital R a dash capital R Nyan.
[00:09:23] So cool right, this is like my favorite tricks and Mocha and you get a nice and noodle consul. And so the more tests you get the longer the rainbow gets behind it. I think it's pretty cool. [LAUGH] The unfortunate part about it, which is why I actually don't use it more often, is I actually like seeing all the different tests that do pass.
[00:09:46] I like seeing the check mark and if you do the Nyan way, it doesn't show you what tests are passing, it just shows you, I have one passing, one failing. Sorry, zero failing and zero pending.