This course has been updated! We now recommend you take the Complete Intro to React, v8 course.
Transcript from the "Configuring & Running Jest" Lesson
[00:00:00]
>> Brian Holt: I think I already have Jest installed. I'm gonna use 15.1.1, but I think as long as you're like in the 15, 16 area, all this should work as expected.
>> Brian Holt: Certainly not lower than 15, okay? And I'm just gonna say jest
>> Brian Holt: Yeah, that's what I gotta do.
[00:00:29] So you're gonna fail your test and why? Well, you're gonna fail on the modules keyword, because we specifically told Babel to not compile modules. But the problem is Node doesn't understand ES6 modules. So now we're kind of in this no mans land of we wanna use ES6 modules, but we can't with Node, but Jest is a Node process.
[00:00:56] So how do we fix that? Well, we can tell Babel that, when in a testing scenario, please compile my modules. So, I want you to go to your Babel.rc, okay? Underneath your presets what you're gonna do is wanna give it an env, which is an object. And we're gonna say when in test we want you to include this additional plugin.
[00:01:29] That's going to be "plugins": ["transform"] es2015-modules-commonjs.
>> Brian Holt: That make sense? So it's gonna apply this additional transformation when in the test environment and not anywhere else.
>> Brian Holt: Okay? So now, what we're gonna do is we're gonna come back to our command line. I'm gonna say NODE_ENV, this is for bash, by the way.
[00:02:20] If you're on like FISH or ZSH, you are on your own. Well, I could probably tell you FISH, I can't tell you how to do it with ZSH. But you're gonna say NODE_ENV=test. Whatever the case right now in time we need your environmental variable of NODE_ENV to be equal to test.
[00:02:39] And we're gonna set a jest.
>> Brian Holt: Did I not save that?
>> Brian Holt: I ran into this last time. So one of the nice features, typically, of Jest is that it will cache your Babel output so it doesn't have to re-compile every time, until you change the Babel environment and then it doesn't know what to do.
[00:03:12] So I think after I say jest, is it noCache?
>> Speaker 2: noCache, you already ran past.
>> Brian Holt: Did I? Okay.
>> Speaker 2: Yeah, it's under --cache.
>> Brian Holt: Jest, so same thing, we just need to run it once with -noCache.
>> Speaker 2: No, it's --no-cache, lowercase.
>> Brian Holt: So, there we go. Once you've cleared out the cache, then you don't have to worry about it anymore.
[00:03:50] But if you do modify your Babel environment, Jest could be problematic.
>> Brian Holt: So it's gonna tell you, hey, I wrote one new snapshot, and all your tests passed, because it's always gonna pass the first time, right?
>> Speaker 2: Gus is asking to see the spec
>> Brian Holt: Sure.
>> Brian Holt: One thing you might notice now, though, is you have this __snapshots__file.
[00:04:21] And this is actually the output of your snapshot.
>> Brian Holt: So you can look in it, this is what the markup kind of looks like for it. So it's rendering everything out for you.
>> Speaker 3: Do you store these in version control?
>> Brian Holt: Sorry?
>> Speaker 3: Do you keep these in version control?
[00:04:40]
>> Brian Holt: Yes, you should keep these in your repository. Because you want all of your teammates to following the same snapshots too.
>> Speaker 4: You're kind of multiple states.
>> Brian Holt: What's that?
>> Speaker 4: It's not possible to have multiple states that are correct.
>> Brian Holt: You can't, so you would write multiple snapshots for each of those states.
[00:04:56] If that was something you were interested in tracking.
>> Brian Holt: But it should be deterministic that every time you run it should have one stage, right? At least for each test it should have one stage.
>> Speaker 4: Or given input.
>> Brian Holt: Unless it's showing the date or something, but even then you'd want some environment for it to be like one specific state.
[00:05:16] Or one specific date for that test, right? So it should be deterministic, your test should be deterministic.
>> Speaker 3: You mentioned that JSON encapsulates Jasmine. I was just wondering, does that mean you could basically just replace Jasmine with Jest, if you had a bunch of Jasmine tests?
>> Brian Holt: I don't know if I'm ready to assert that, but I'm gonna assert that it's pretty damn close.
[00:05:43]
>> Speaker 3: Okay.
>> Brian Holt: I don't know if it's drop-in, that's what I'm trying to say, but it's probably pretty close.
>> Speaker 4: So the only reason this works is because we've got a static data file that's the same every time?
>> Brian Holt: Yep, so going back to this, now I can run it as many times as I want.
[00:06:01] I don't have to put the --no-cache in anymore. So NODE_ENV = jest, or test jest.
>> Speaker 3: Can we do a push?
>> Brian Holt: Yeah, momentarily. So it compared it again, right? And the snapshot matched, so it just keeps doing that, right? And it'll pass, cuz we haven't changed it all.
[00:06:26] So, let's actually go modify search.js so it does fail. So I'm gonna change svideo to be something else.
>> Brian Holt: Okay, so I've changed it to say something else now. And if I run NODE_ENV=test jest.
>> Brian Holt: Now I get a failure that says, hey, something changed since the last time I ran this snapshot, gives you the whole output.
[00:06:56]
>> Brian Holt: But it's gonna tell you right here, hey, this is what my snapshot has, svideo. Now it has something else, I can't pass this, I don't know what to do with this.
>> Brian Holt: So, what you do with this at this point you say, okay, well, this is actually what I expect, I want it to say something else now.
[00:07:22] So I say, -u as saying, okay, run this again, but update my snapshot.
>> Brian Holt: And so you said, okay, it updated one snapshot, because you told me to. And that's how you do it.
>> Brian Holt: But let's go back and change it back svideo. So if you run it without u, it's gonna fail again
[00:07:48]
>> Brian Holt: But now we want to update, so we'll give it back and now we're in good shape again.
>> Brian Holt: I think snapshot testing is phenomenal, because it's free testing, right? They're not exactly the most robust, best tests, but the fact that they are so cheap to write. Like, the test itself is what, four lines?
[00:08:14]
>> Brian Holt: Three lines, three lines of actual code to get that test, right? Writing a test in three lines that tests all of the markup? Pretty compelling to me. And it's up to you to decide if you think it's compelling.
>> Brian Holt: But, like I said, it doesn't really tell you too much, but it's just a good litmus test.
[00:08:31] And it's so cheap, it's almost free to write.
>> Speaker 2: Question, is there a way to shorten that diff output so you get just a contextual diff?
>> Brian Holt: Probably, I wonder, jest --help.
>> Brian Holt: It's got all sorts of really interesting things in here.
>> Brian Holt: --json,
>> Brian Holt: --debug, --coverage.
>> Speaker 2: --onlyChanged?
[00:09:04]
>> Brian Holt: --onlyChanged?
>> Speaker 2: No.
>> Brian Holt: No, I mean the answer's probably, it has all sorts of really interesting features. Another one that's really interesting to me is --watch. So it's gonna be watch on the side, right? And every time that I change something in my codes, let's say if I come back here to ShowCard.
[00:09:25] And say, yeah, this is now gonna say we're gonna have an h1 here that says h1 something, and I save. It's going to rerun the test suite and them I'm gonna get the answer, right?
>> Brian Holt: But it's just gonna keep re-running. And only, for the most part, I think it can run just the test that are affected, which is interesting as well.
[00:09:52]
>> Brian Holt: You can press a at any time, it'll re-run all the tests. You can say run only ones that have changed since last time. You can update if you press u, you can press q to exit. So --watch is another interesting tool as well.