Transcript from the "Testing Reducers" Lesson
>> Brian Holt: Okay, so we fixed our tests for React. Everything's good now.
>> Brian Holt: We're going to go to reducers now, and we're going to test our reducers. Which I promise is much more pleasant, so reducers.spec.js.
>> Brian Holt: So one of the biggest advantages of using Redux, if not the biggest advantage for using Redux, is reducers are stupid easy to test.
[00:00:34] Because of the way that they work, they're designed to be incredibly testable, which is awesome. They are fact so easy to test that the dev tools will automatically generate tests for you. So we don't even have to write them, they're that easy to write.
>> Brian Holt: So,
>> Brian Holt: What I want you to do is I want you to go to your app here, and I need to run it, npm run dev.
>> Brian Holt: Okay, refresh the page.
>> Brian Holt: What I want you to do is I'm just gonna paste house in here.
>> Brian Holt: Okay, I'm gonna paste house in here. I'll refresh the page. Okay, so that was one atomic action. Went from nothing to having house, right? I can click on this right here,
>> Brian Holt: And see where it says Action, State, Diff, and Test? Click on test,
>> Brian Holt: And it wrote a test for you.
>> Brian Holt: And you can also get this in Jest, Mocha, Tape, or AVA. Since we're in Jest, we're just gonna keep doing that. So I'm just going to copy,
>> Brian Holt: Paste. Let's get the, this path is wrong, ./reducers.
>> Brian Holt: Bam, just wrote a test.
>> Brian Holt: There's one unforgivable thing that this test has though,
>> Brian Holt: Semi colons. [LAUGH]
>> Brian Holt: Yeah, I think there's a couple things you have to fix in here so that it'll pass lint.
>> Brian Holt: Spaces,
>> Brian Holt: Okay, I think that'll pass lint now
>> Brian Holt: So now if we run tests again,
>> Brian Holt: npm run test,
>> Brian Holt: Now we have four tests.
>> Brian Holt: Another good one to run, so if I come back here to my,
>> Brian Holt: Dev tools, I click init. When your Redux store is starting up, it sends off this init action.
>> Brian Holt: Which is why it's important that you provide for actions that you don't recognize, and it's also important that you have a default state. And you can also write a test for it by clicking on this init.
>> Brian Holt: And grab the test,
>> Brian Holt: And that's another good one to have too.
>> Brian Holt: So I usually name these after the actions that they're testing.
>> Brian Holt: This was,
>> Brian Holt: Set search term.
>> Brian Holt: Okay.
>> Brian Holt: But I mean, even look at these tests real quick, right. So you pull in a reducer,
>> Brian Holt: So a reducer, this is actually the root reducer that it's pulling in, right?
[00:04:44] It's then dispatching a random looking test to it, right? Some, or semi-random looking test, but this is the state that it's dispatching to it. And then it's expecting to get back a state that looks like that.
>> Brian Holt: So that's the nice thing about these reducers is because there's no state with them.
[00:05:05] So it is just input output, and you don't have to worry about anything in the middle, it's a total black box. Any questions about that? That make sense?
>> Brian Holt: If you want to, you can go and grab one for details as well.
>> Brian Holt: I need to run dev again.
>> Brian Holt: This is one will be a little bit longer, but, right, cuz this is everything that comes back from the API.
>> Brian Holt: But nonetheless, ADD_OMDB_DATA, and there it is.
>> Brian Holt: So I'm not gonna fix this, cuz this definitely would not pass lint. Cuz standard like spaces between all those things, and I'm way too lazy to go do all that right now.
[00:06:11] But, that's how you would do it. And so now, I want to get rid of that import as well, cuz you don't need that.
>> Brian Holt: If I do npm run test,
>> Brian Holt: Six tests, and I barely wrote any of them [LAUGH]. Four of them, the computer essentially wrote for me, so that's pretty great.
>> Brian Holt: Any questions?
>> Brian Holt: So typically you test the hell out of your reducers. For every reducer you have you should have a test, that's definitely a thing. You can test your action creators, specifically the ones that if I pass it a search term like this, I should get back an object like that.
[00:06:58] That's a pretty easy test to write, but a pretty important one. The async, like thunk action creators are a lot more difficult to test.
>> Brian Holt: It can be done, I just typically don't to be totally honest. I'm more interested in the reducers, but-
>> Speaker 2: Functs should be pretty benign.
[00:07:21] I mean, it's just a function standing in place of a value, usually. There shouldn't be a whole lot of logic to test in them.
>> Brian Holt: Sure, but, I mean, for example, our thunk calls axios, right, which is gonna try and make an HTTP request.
>> Speaker 2: Right, but you wouldn't want to unit test that anyway.
>> Brian Holt: Right, I mean, I don't, right?
>> Speaker 2: [LAUGH]
>> Brian Holt: But some people are intent on having 100% coverage. So it can be tested, it's just un-fun to test.
>> Speaker 2: Seems to having a slight problem with their stuff. They're using jsx, I don't know.
>> Brian Holt: Jsx, like the file extension?
>> Speaker 2: Yeah.
>> Brian Holt: So I don't think Jest automatically picks up jsx file extensions. So first of all, if you just change it to be js, it should just work. Otherwise you can configure Jest, and I leave you to do that on your own terms.