This course has been updated! We now recommend you take the Complete Intro to React, v8 course.

Check out a free preview of the full Complete Intro to React, v2 (feat. Router v4 and Redux) course:
The "Testing the Search Field" Lesson is part of the full, Complete Intro to React, v2 (feat. Router v4 and Redux) course featured in this preview video. Here's what you'd learn in this lesson:

The last test Brian includes will verify the search field is working properly. Brian uses the test framework to simulate a search term being entered and compares the filtered results to the expected show count. The code for the application up to this point is on the v2-12 branch.

Get Unlimited Access Now

Transcript from the "Testing the Search Field" Lesson

>> Brian Holt: So, let's do one more test. We wanna simulate if someone searches that if that works. So, we're gonna run one more test, ('Search should render correct amount of shows based on search.
>> Brian Holt: I'm gonna make some searchWord, that's gonna be equal to 'house. In this particular case, you could make it something else that you know the answer to.

[00:00:38] You're gonna say, const component.
>> Brian Holt: = shallow(<search />), then I'm gonna do a component.find and I'm gonna look for input. Typically, I would make this more specific, but I know for a fact this has only one input. And by the end of the workshop, there is still gonna be one input.

[00:01:01] So I'm just gonna go with that and I'm gonna do a simulate, a change event and I'm gonna pass it my synthetic event, target: value.
>> Brian Holt: SearchWord.
>> Brian Holt: Space.
>> Brian Holt: So, it's basically going to fire like an event. The caveat I wanna throw out to you here is that Enzyme does not do event bubbling for you.

[00:01:53] So if you want to simulate a change event, you need to simulate it at where the handler is. For the most part, that's not really a problem. But if you're expecting it do event bubbling, that can be quite frustrating. So, just keep in mind that it does not bubble events.

>> Speaker 2: Yeah, this is for unit testing, not the other thing.
>> Brian Holt: Yeah, integration testing.
>> Speaker 2: Integration testing. Thank you.
>> Brian Holt: And then I typically would do this differently. But for the sake of time, I'm just gonna kind of like copy some logic. I'm gonna put this filter statement here.

>> Brian Holt: So, I'm just gonna copy this straight out of search. Normally, I would abstract this into another function. Import it into both places, so that you're using the same logic. #toolazy, I'm not going to right now. So I'm gonna say, preload.shows.filter
>> Brian Holt: This is gonna be the same filter.

[00:03:06] This is gonna work the same way, but you would just want the length of this.
>> Brian Holt: And now you're gonna say, expect(component.find(ShowCard).length).toEqual(showCount).
>> Brian Holt: Now you can get more specific and say like, I specifically expect there to be House of Cards and I expect there to be, and you can get more granular than that.

[00:03:46] But for the most part, the count, at least for me is going to be a sufficient judge, but I kind of err on the side of like let's write quick and easy tests that are have strong correlation to working. And then if it breaks later, let's write stronger tests.

>> Brian Holt: So, let me validate that this still works.
>> Brian Holt: And it failed, why did it fail?
>> Brian Holt: It cannot restate. I said, state.searchTerm here. I actually just want searchWord.
>> Brian Holt: SearchWord, cuz there's no state here. We're just using the searchWord up here,
>> Brian Holt: So, let's try that again.

[00:04:46] The dangers of copy paste.
>> Brian Holt: Now, it works.
>> Brian Holt: Does anybody have any questions of why that works or how it works?
>> Brian Holt: It's kind of an interesting test.
>> Brian Holt: So, I got like maybe three more tiny things to work and then we we'll be done. So what I've shown you is the, in my opinion, the most compelling reason to use Enzyme which is the shallow render.

[00:05:27] The nice thing about the shallow render is it doesn't pull on JS DOM. It doesn't pull on a browser. It doesn't use Phantom or anything like that. It's purely JavaScript and it's really fast. These test that you see here are running pretty fast. I run my test suite in 1.5 seconds, that's not bad and that includes all the bootstrapping and everything like that.

[00:05:47] So running the shallow renderer is like no problem, let's do it a whole bunch. You can use it willy nilly and you're not gonna slow down your tests. There is one level more. Sorry, go ahead.
>> Speaker 2: I was going to. They question is what would you recommend for an integration test?

>> Brian Holt: I mean, selenium, I suppose. I have a hard time saying, I recommend selenium, but that just seems to be the de facto answer.
>> Brian Holt: Or higher QA, that's probably my better answer is higher QA. [LAUGH]
>> Brian Holt: I don't know if I have a good answer for that.

[00:06:24] We use selenium, I'll put it that way.
>> Brian Holt: So, Enzyme has two additional depths of rendering. One of them they just call it render, but that's actually going to bring in JS DOM which has to bootstrap and JS DOM is like a copy of the DOM, but on JavaScript.

[00:06:43] So it's not quite as bad as having this like open Chrome or open Phantom or something like that, but it's pretty slow. So, you can greatly slow down your tests by bringing in render. So I would recommend avoiding it, if you can like at all costs like work really hard to make sure that you don't pull the render like the normal render.

[00:07:07] It is like I said much slower and then there's one more that's even slower than that, but gets even also. I guess the question is why would you use render? If you need to interact with DOM APIs, if you need to do more crazy things than we're doing here, usually it's to interact with DOM APIs, then you need to bring in render, cuz the shallow render doesn't have any DOM APIs available.

[00:07:36] And if you need to go full on static rendering like completely render everything out and have all sort of like DOM exploration available to you. You can actually use what they call static rendering, which I think will also use JS DOM and then it wraps cheerio on top of that which Cheerio is a great library if you've ever used it for just doing like offline stack analysis of your HTML.

[00:08:05] It has like a j quack interface to it. But again, even slower. I definitely recommend avoiding it, if you can.
>> Speaker 2: Do Jest and Enzyme need to run in Phantom or anything? Cuz I noticed without any, we didn't have to configure anything and no Phantoms run in.
>> Brian Holt: Nope, it's just Jasmine.

[00:08:23] That's the only hidden dependency here. So, that's why it's pretty fast. Yeah, as much as you can avoid bringing Phantom is a good thing. Yeah.
>> Speaker 2: Francoise asks a question. It seems Enzyme does more that Jest when you use Jest versus Enzyme. My response was you use them together.

>> Brian Holt: Use them together. I mean, Enzyme can be used with mocha like my other workshop uses enzyme as well, the version one of this workshop. So if you're testing React components, you just use Enzyme. That's almost 100% correlation.
>> Speaker 2: Off topic question.
>> Brian Holt: Sure.
>> Speaker 2: Dinard is asking, where do you follow new technologies and understand when to you use them?

>> Brian Holt: I follow a lot of people on Twitter which is a really crappy answer, because who do I follow on Twitter? People. But honestly, that's where I get it. I get water cooler talk at Netflix. Again, not helpful. So I don't read hacker news as much these days, because everyone's a jerk on there.

[00:09:29] The subreddit for JavaScript on Reddit for the most part, it's pretty good.
>> Brian Holt: That's probably it and then just I play around on stuff on the weekend for fun.
>> Speaker 2: Do you have a list on Twitter that you put your favorite people on?
>> Brian Holt: I don't. Yeah, I have my thousand followers or thousand people that I follow.

[00:09:50] Yeah.
>> Brian Holt: It's 5, I have two more things to talk about which should be pretty fast.
>> Speaker 3: [INAUDIBLE] 20 minutes left, this is the left card to talk all the way through.
>> Brian Holt: Yes.
>> Speaker 3: We're gonna have to take a break if this goes more than 20.
>> Brian Holt: Nope, I can do it like ten.

[00:10:16] So, just brief treatise. We'll save the rest of the questions for the end, but I really don't do this very much. I don't really test my react components that much. What I do is I abstract my modules out, my business logic into modules and I just test the hell out of the modules and I very rarely test the actual react components themselves.

[00:10:39] Just because at Netflix we do a lot of AB testing, so the amount of thrash we have on markup is just huge. I'll push at the end, but there's no more code to write today. So yeah, we'll be fast.
>> Brian Holt: So that's just my personal feeling on unit testing and I feel like that is controversial, so take it with a bag of salt.

[00:11:05] But yeah, I don't do a lot of unit testing on my React components.