Transcript from the "Unit Testing with Jest" Lesson
>> Let's look at what a test is. So here's what it looks like. I'm actually just gonna walk through it versus just trying to tell you what it is. So let's just make one. I'm going to go into our handlers. I'm gonna make a new folder, and I'm gonna call it __tests__.
[00:00:22] Why did I call it that? That's one of the default folder names that just it looks for, so I called it that. I think you can also just call it tests, maybe even specs, so many different names that it looks for. I just don't remember which one you have to tell it to versus which ones are the defaults anymore.
[00:00:37] I just know for sure that this is a default one that it looks for, so I'm calling it that. You may also just wanna put all your tests on the route somewhere and just have all your tests there versus having your test live next to what you're testing.
[00:00:49] My mood changes a lot. Today, I feel like putting the test near where the things that I'm testing, so I'll have to write long import statements. That's literally the only reason. [LAUGH] Otherwise, I might put them all down here. I don't know, I just don't feel like writing long dot, dot, slash, dot, dot, slash, dot, dot stuff today, so I'm not doing it.
[00:01:08] Okay, so let's write a test for, I don't know, users. Let's do that. So I'll say user.test.ts. Those icons are pretty dope. I like those icons. So in the flavor of, did Mocha come before Jasmine?. It's been so long, I can't remember. I think Mocha came before for Jasmine.
[00:01:56] And that jest environment are going to inject these functions that we're using globally. So don't have to import any of this stuff that we're using. They're gonna be given to us at runtime, they're gonna be injected into the code. So describe is just an organizational function you can use to describe, I don't know, think of it like the module that you're testing, maybe the file that you're testing.
[00:02:16] In this case, we're testing the user handler, okay? So I'm gonna put that there, and then I can give it a callback function. And then for each thing that I wanna test, I mean I can even add more describe if I want to, but I don't have to.
[00:02:31] But for each thing that I wanna test, I can either do something called it, not the clown, but the word. Or I can do something like test, I'm just gonna say it. And the reason I say it because it reads better. So usually, it goes something like this, you can say, it( should do something when something happens), right?
[00:02:58] You would put a description like that, whatever it is, the thing that you're about the test right now, the specific condition of what is it you're about to test, that's what you would write. This doesn't functionally change anything about the test. But when you visually see it in output, you'll know what tests failed or what passed based off of these descriptions and these blocks here.
[00:03:18] So try to actually put some intention in those words. And you put a callback here. And then I can use this built-in really cool function called expect. And I can write my assertions, I can say, I expect 1 to be 1, right? 1 is 1, so this should pass.
[00:03:40] So now, To actually run this test, we just need to tell just to do it. So I'm gonna go into, Package json. We got this test script here, I'm gonna get rid of all of its contents, and I was gonna say jest. Okay, And then to run the test, I can just say npm test.
[00:04:17] And just like that, jest went and found the test because of the folder, that name that I created. You can see it's pointing to the file here. User handler is what I put in the describe block. So this is why I said it's just for organizing. And then here is the actual assertion that I ran.
[00:04:34] And the green check just means that it passed, the word passed means I passed. And here are just more information about all the tests I ran. I ran one test Suite. A suite is basically a describe block. And then each time there was an it function, that's a test.
[00:04:50] So I ran one suite with one test, and they all passed. Right, so an example of a failing test would be something like, well, I expect that to be 2. Okay, well, that's not 2, that's 1 right? And it'll tell you, it'll say, user handler should do something when something happens.
[00:05:12] We received this thing in red, which was 1, But we expected it to be 2. So those things don't work, 1 is not 2, so it failed. Any questions on the unit test?
>> So you just typed jest in the terminal?
>> If you go to your terminal and type in jest, you'll probably get an error, because-
>> So where did you do that?
>> Yeah, good question, so actually, this brings up a really good point. If you install a CLI into your application, just like we did, just as a CLI.
>> But we installed it locally into our project. We didn't install it globally onto our computer, so we can't actually just type in just like this, because we didn't globally install it.
[00:06:05] We locally installed it, so we'd have to do something like node_modules, right? We have to do that, I think I talked about it earlier in the course. So if you wanna actually use it, the package json is really smart. So I added it here in scripts test. And npm is actually smart to know that like, if you have just installed locally in here, which we do, it'll use the local one, but if you don't, it'll use the global one.
[00:06:31] Whereas the terminal is not that smart, your terminal is not gonna know that you have something called jest installed in this project. It's actually looking on the root of your computer for it, in the bin folder. So it won't work here, unless you install it globally. So yeah, you can put it here and then you can just say npm test.
[00:06:52] Fun fact, test and start are the only commands in npm that you don't have to put the word run in front of. Every other command, you gotta put npm run dev or npm run whatever, but not test and start, you can just say npm test, npm start. I don't know, somebody made that up.