Transcript from the "Testing Filtering with mount()" Lesson
>> Brian Holt: Shallow is really useful for checking to make sure mark up got in, that things are getting rendered the way you expect but if you actually want to be interacting with it you have to do a little bit more. You have to be able to like have events happening, like Shallow doesn't have events, it doesn't have anything like that.
[00:00:17] It just basically like gives you a string back of the mark up and gives you a couple of easy methods to be able to look at it. Another thing that's really nice but enzyme which I'm not particularly, actually we're gonna look at right now, is you can kind of use JQuery-like syntax on it and it works.
[00:00:32] And that's really nice for a lot of us that have done way too much JQuery code. So we're going to do some of that right now. Okay so we have shallow. But we need to go one step further. We need like a real dom-esque environment right. So we're going to bring in something called mount as well from enzyme.
[00:00:52] The trade off here is that. So first of all as far as I know everything you can do with Shallow you can also do with Mount. The trade off being that Mount is quite a bit slower than Shallow. Shallow's pretty damn fast. Okay so it should filter correctly given new state.
>> Brian Holt: I want to say const wrapper = mount search.
>> Brian Holt: Okay and then I want to say const input = wrapper.find.search-input. So again, jQuery like syntax here, most of us should feel pretty comfortable with that, if not it's okay, but this is relatively how jQuery would look. This is going to go in and find our input.
[00:01:54] If you remember from our search.jsx. It's going to go grab this one right here. And now, we can basically programmatically interact with it.
>> Brian Holt: So what we're going to do here is we're going to say, input.node, which is actually going to be talking directly to the DOM node.
>> Speaker 2: Can you scroll up a little bit.
>> Brian Holt: Yeah.
>> Speaker 2: Thank you.
>> Brian Holt: Let me just put a bunch of empty space up here.
>> Speaker 2: Thanks.
>> Brian Holt: Okay, .value, input.node.value = 'house', right. Now, I'm gonna say, it doesn't actually do these on change events for you so you actually have to tell it I changed it, here's the event that actually happened.
[00:02:39] So I have to say input.simulate('change'). Basically saying I changed the value and now I'm gonna give you a change event. And then that's gonna to fire our on Change event inside a react. Does that make sense? Okay and then here we're gonna say expect wrapper.state. So we can actually inspect the state in our component for the search term.
>> Brian Holt: To equal ('house'). So basically, first thing we're gonna test is, does the state match the value of the input. Basically we're testing to see, if anywhere our two way data binding got broken, and then we're also going to test, (wrapper.find('.show-card)).length. So unfortunately we can't do this magic up here where we're just using the constructor for the, excuse me, we can't use the component to find it, we actually have to search on the CSS class.
[00:04:00] Mount just doesn't have that capability. So I guess that's not totally true that shallow and mount aren't quite the same. They are a little different and that's just the way it is. And then, to equal to, right, cuz we know we have exactly house of cards and we have a fuller house and it shouldn't show anything else.
[00:04:20] So basically we're saying if I search for house, I should only be showing two different show cards and I should be dropping the rest of them. So basically at this point we're just testing, is the search part of it, is the filtering part of it working? So to answer our friends previous question, this is indirectly testing if our filtering works correctly.
>> Brian Holt: Which is always dangerous, indirect testing is not usually the best way to do it but it works for me at this time.
>> Brian Holt: Okay, so let's go make sure it works and then we'll take some questions on this.
>> Brian Holt: Npm, run test.
>> Brian Holt: Cool, so notice it says this.
[00:05:09] This is basically means, you wrote a slow test. [LAUGH] And it tells you how long it took you to run this test. And that is just the nature of using mount. Mount is just slower, and there's not really much you can do about that. Okay.
>> Brian Holt: Any questions here?
>> Speaker 3: They're asking why we're using mount instead of shallow and it's because shallow doesn't allow for the interaction?
>> Brian Holt: Yep, that's precisely it. We wanted to be able to simulate events and change the value of the input and that's why you have to use mount here and not, because shallow doesn't allow for that.
>> Brian Holt: Other questions?
>> Speaker 4: So, you're recommending use shallow when you can, and then use mount if you have to?
>> Brian Holt: Precisely.
>> Speaker 4: Okay.
>> Brian Holt: That is eloquently put, thank you. There is actually even one level further than mount, you can actually do, it's called static rendering. Which is actually going to be using JSDOM in Cheerio.
[00:06:22] That actually creates a very browser like environment. And we'll have to use that at the end of today because once we start introducing tools like redux and things like that that it requires an even more realistic browser environment and it's even slower. So yeah, you kind of go down the hierarchy.
[00:06:40] Can I do this with Shallow? No. Can I do this with Mount? No. And then eventually you say, can I do this with Static Rendering? Okay, I guess I have to use static rendering.
>> Speaker 5: If you're using shallow, do you get access to state or other methods?
>> Brian Holt: No, not as far as I know.
>> Speaker 5: You just get access to the DOM output.
>> Brian Holt: You might get access to initial state. You know I'm not sure to be totally honest.
>> Brian Holt: Yeah, I'm not exactly sure what the limitations are and some are still pretty new library. I think it's been out for about six months or so.
[00:07:14] That's at least as long as I've been using it anyway, but good question though. Any other questions?
>> Speaker 3: Would this work properly if you were debouncing the inputs?
>> Brian Holt: Yeah it would work because,
>> Brian Holt: This is almost like a copy and paste, right? We're inputting house all at once.
[00:07:38] It's not like we're doing H, then O, then U, then S, then E. So this should work okay.
>> Brian Holt: I think actually technically, I don't think you'd use a debouncer, I think it'd be a throttle.
>> Brian Holt: Because you definitely want it to run at the end of whenever they stopped typing right?
[00:08:03] Yeah, I might have that backwards. Don't ask me. I don't remember. Anyway, [LAUGH] any other questions?
>> Brian Holt: Okay, I think that's the end of my unit testing thing. So I'm just gonna push a branch real quick if anyone wants to grab the tests. The only thing about all these tests that we just wrote, we're now going to go break all of them.
[00:08:28] [LAUGH] And that's just the unfortunate reality of writing UI code.
>> Brian Holt: So git checkout -b fen-15, git add-A, git commit -m FEM step 15, git push origin fem -15.