Check out a free preview of the full Complete Intro to React, v3 (feat. Redux, Router & Flow) course:
The "Testing the Number of ShowCards" Lesson is part of the full, Complete Intro to React, v3 (feat. Redux, Router & Flow) course featured in this preview video. Here's what you'd learn in this lesson:

To verify the number of ShowCard components matches the number of shows in the JSON data, Brian writes another unit test. After the test is written, Brian demonstrates how to break the test by including a default search term.

Get Unlimited Access Now

Transcript from the "Testing the Number of ShowCards" Lesson

>> Brian Holt: So let's go ahead and add two more tests here. The first I'm going to say is, hey, given a particular type of search, we want to make sure we're rendering a correct amount of cards, right? So going back to our app here, if I type, what do I do?

>> Brian Holt: If I type, orange, right? It should only render one, what's one that will render two? Black? Yep, if I type, black, it should render Black Mirror and Orange is the New Black, right? That makes sense? So I want to test that functionality to make sure that the search is happening the way I anticipated.

[00:00:37] So, let's go in here. The first thing we're going to do, is we're going to import show card, as well. So import ShowCard from ../ShowCard, and we're also going to import preload from ../../data.json
>> Brian Holt: Okay under that we're gonna say test. Search should render correct amount of shows based on search term.

>> Brian Holt: Something like that.
>> Brian Holt: Sorry, that's the third test we're gonna write. [LAUGH] Getting a little ahead of myself. The first one I just wanna make sure is that given no search term that it's gonna render everything. So we'll put that third test aside for a second. Then we'll say search should render correct amount of shows.

>> Brian Holt: So just in case if you're not familiar with the testing in JavaScript or in general, this is the string that you're gonna be shown if the test fails. So you want something descriptive enough that you can read that line and say, I know what failed. That's the goal here.

>> Brian Holt: Okay, so I'm gonna say const component = shallow search.
>> Brian Holt: And then here we're gonna say expect preload.shows.length,
>> Brian Holt: To equal,
>> Brian Holt: Component .find(ShowCard).length);.
>> Speaker 2: You said that's what should be shown if it fails?
>> Brian Holt: Right.
>> Speaker 2: So for the first test, search is trying to correctly what it shows on the fields.

>> Brian Holt: Right, so it's gonna say this is the test that failed and it's gonna highlight it in red. So search does not render correctly, right. So that's kind of. I see what you're getting that you would say something like search the .render correctly, right, like a more error type message.

[00:03:21] That's not typically the paradigm that you write it with. Typically you write with a paradigm like this is what this is testing right? This is testing this search renders correctly, right? And then it shows in red that this did not happen, right? That's kind of the implicit way of doing.

[00:03:36] It's up to you, right? If that works better for you than do that. Yeah Mark?
>> Speaker 3: Is there a describe wrapper to group the tests by type?
>> Brian Holt: There is, I could totally wrap these with describe. In fact I'll show you if you're interested. Describe search right this would be like a search test suite, and then I would wrap all of these test statements in that.

[00:04:05] And then typically inside of describe you would call these it. It and test are the same thing. And then here I would write instead of saying search, right? I would say renders correctly.
>> Brian Holt: So it's like instead of saying like test that this happens. It says it renders correctly.

[00:04:28] It should render the correct amount of shows. It should render right? That's the way that you would do that. Totally up to you, totally valid. I would do that if I had multiple things I was testing in one suite, but in this particular case I've searched that's tied to just that search component.

[00:04:46] So it makes sense to put them all on one top level thing.
>> Speaker 4: I know with MOCA they advise against using aero functions in their testing because context, is that not true of Jest?
>> Brian Holt: Their docs use it so that's good enough for me.
>> Speaker 4: You can sort of get away with it in MOCA too.

[00:05:08] I was just curious.
>> Brian Holt: Yeah I haven't heard anything to that effect but it would this is less useful for stack traces. So if I have an error in here. I'm gonna get an anonymous function and not like a named function so. You have to make a trade off.

[00:05:28] I don't want this line 17 test to run right now cuz it's not actually doing anything, so you can just put x test, and it's just not gonna run it. So for example, if this test was flakey and I didn't wanna run it right now while I'm testing other things, just put x test in front of it and it'll stop running it.

[00:05:44] Yeah, and then when you're ready for it to run, you can just take the x off.
>> Speaker 3: Is that the same with the it?
>> Brian Holt: Yep, xit and also xdescribe works for entire suites as well.
>> Brian Holt: So let's go ahead and run our test again.
>> Brian Holt: So you can see here, it says 1 skipped, that's the one that we skipped at the bottom, and 2 passed, right?

>> Brian Holt: So let's go make it fail. It's always a good idea to make sure that your tests fail when you expect them to fail, too. So I'm gonna go to Search.jsx, and I'm gonna game back in here. So now I'm gonna expect it to render A show card for every item but it's not gonna do it.

[00:06:26] It's only gonna render Game of Thrones right? So if I run this test again,
>> Brian Holt: You can see here I failed whatever, I failed my snap shot, that's fine. I expected that. So, in this particular case I expected the value to equal 1, and I received 15. I have these backwards, don't I?

[00:06:51] Okay, hold on, I do this all the time.
>> Brian Holt: So what I have in expect should be in toEqual.
>> Brian Holt: Yep, yep, yep, yep. So what goes inside of expect is what you're testing, and what goes inside of to equal is what the answer should be.
>> Brian Holt: It's minorly semantic, but you get more useful failures, right?

[00:07:22] So now if I run this again I expected to get 15, right, but actually only got 1, right? The reason by it, it only rendered Game of Thrones and I expected it to render all 15 shows that I have possible. Does that makes sense?
>> Speaker 5: The focus is [INAUDIBLE] also like the d describe, and the i, it like how in Jasmine.

>> Brian Holt: Yeah, you can use all of those.
>> Speaker 5: Okay.
>> Brian Holt: Cool, so I'm gonna go back to search.jsx, I'm gonna drop this, save it.
>> Speaker 4: Sorry I can understand why you get confused about that because it's expect actual value to equal expected value.
>> Brian Holt: Yep, totally, right?