Testing React Applications, v2 Writing a React Test Solution

[00:00:00]
>> Kent C. Dodds: Okie dokie, let's go ahead and make this happen. So I've got a couple examples up here. So we're gonna have two different tests I think that would make sense in this situation. For this, I just wanted to get your hands on the keyboard writing your first test really quick in the workshop.

[00:00:16] So it doesn't have to be a super high fidelity test. We can talk about the tradeoffs of more high fidelity tests, and maybe some alternative approaches to testing this. But let's go ahead and import react and react-dom, and we'll import our item-list. And then here I'm going to create a container to render things to.

[00:00:38] So we'll say container = document.createElement('div'). And then I'll ReactDOM render my UI, the item list, to that container. But the item list, if you check it out here, it's going to expect that. It's not going to default it, so let's go ahead and provide items, that's what it's called.

[00:01:00] Empty array. And now we can actually console.log container.innerHTML. So it's just regular DOM node. Sweet, and it just says no items. Okay, so we can verify that. We could just say, there are various things we could say. We could say the whole inner HTML says no items. And that's what I'm gonna do actually for this, expect.toBe no items.

[00:01:29] Cool, and that passes. So the reason why I wouldn't actually do this is what if I decide for style reasons or whatever, my designer comes in and says, hey, we want to add a class to this or something. So I'm going to put a span here and then a span.

[00:01:43] We'll get rid of that stuff. And now my test breaks. So my test breaks, but the actual value that this is creating for the end user. As far as the end user is concerned, this is a total refactor. It's not changing the behavior for the user. It's not changing anything of significance.

[00:02:07] And so the fact that my test broke for a change like this, that's frustrating. This is one of the reasons why testing UI is so frustrating and people kind of give up on it. It's because we're, technically it's not actually a refactor. It is changing the way that it works.

[00:02:24] But as far as the user is concerned, they don't care that it's a span or a div or an h1 or any of that stuff. They just care about what it looks like. And so when we're testing, we want to focus more on what are the important parts that we wanna verify about this.

[00:02:39] And so sometimes that leads to may be a little less fidelity type of test. But in general you can still kind of get the confidence you're looking for without having to be so strict about what your test is like. So what we're gonna do instead of checking the inner HTML is we're going to check the text content to match no items.

[00:03:10] And now with that, I can style this differently. I could put this in a div. And so that actually will still work cuz the way text content works. So yeah, lots of different things you can do about this. And I'm totally cool with focusing more on what's the user's experience going to be and how do I want to verify that user experience versus making sure that my DOM structure is always the same.

[00:03:38] Because that doesn't really matter for the user. Yeah?
>> Speaker 2: I was just gonna to point out, I was initially confused about this because I thought that to match was an exact text match.
>> Kent C. Dodds: Mm, yeah, sorry.
>> Speaker 2: And it turns out, it's a regex match, which is obviously broader.

[00:03:54]
>> Kent C. Dodds: Yeah, yeah. So I kinda tried to show you in this example that some text content matches just text. So it can match a sub text, so. Sorry, that's kind of a jest specific thing. I probably should have also referenced everyone to the Jest expect documentation. So I'll send you off to that, here in the chat.

[00:04:22] In a second, I'll get that to you, or somebody can paste that in the chat. Cool. Any other questions about that? Yes?
>> Speaker 3: So not really related, but kind of on the same vein, you started talking about DOM structure and stuff like that. Do you ever, for branding purpose, will you ever verify anything is visually correct using, test it like this, or in Cypress or somewhere else?

[00:04:49] Or do you generally leave that to sort of the manual testing?
>> Kent C. Dodds: Yeah, that's a great question. So there are various totally reasonable reasons that you would want to verify things look the way that they should. How many people have shipped a CSS bug? Like everybody has shipped a CSS bug.

[00:05:12] So verifying CSS or the style of the page is actually quite difficult. It's getting easier. There are a lots of tools out there for visual regression testing. And those tools are getting better. We're not going to cover any of those. But I know Cypress supports screenshotting, and you can use that to do diffs.

[00:05:31] There's also Puppeteer that you can use with Jest to to do these visual diffs. And I know there are tools that kind of come out of the box with these different capabilities. And so yeah, we're not gonna be covering visual regression testing. One other thing that I should mention and that we'll actually see is, the application we'll be testing uses Glamorous for its styling, so a CSS and JS library.

[00:05:58] And so because all of that's happening in JavaScript, you can actually make assertions on the styles. And so that can kind of get you a middle ground between an actual visual regression test and just a regular in Node test. And so it gets you a little closer there without lots of the drawbacks of visual regression testing with regard to how difficult it is to maintain and that kind of thing.

[00:06:25] So if the look and feel of your application is of great concern. Especially if you're white labelling and the style can be applied differently, then yeah, you might wanna add some additional tests to verify that and that can work. And you might be able to accomplish that in regular JavaScript tests.

[00:06:49] But in general, you probably wanna use a visual regression tool for that. Okay, cool. The title of this is no good, so renders no items when no items are given. Something useful, so when it fails, like this. You can read the test and understand what it's supposed to be verifying.

[00:07:18] For our next one, let's fix this. We want to test that it renders the items given. And here it's gonna be quite similar, so we'll just stick that there. And the items, I gave you a list here, we'll just use that same one.
>> Kent C. Dodds: And here, we can just verify that text context matches apple, and orange, and pear.

[00:07:51] And that will get our test passing. This is not a high fidelity test at all, because this item list could be like changing the order. Or the fact that it's a ul and an li could be actually important, or various things. But I am trying to illustrate that you should really only be testing the things that are actually important for your verification, to make sure that you're confident.

[00:08:19] So what are the chances that somebody's gonna change this ul to an ol on accident, and not intentionally? Not very great. But if you are concerned about the structure, then you could use a snapshot test for this stuff. And we'll talk about that more later. But yeah, in general, this is a pretty good test to verify that at least those things are being rendered.

[00:08:45] Each one of the items are being rendered. And so I don't know if I'd let this go through. I'd probably merge this pull request, a pull request for these tests. But, you could make this more high fidelity, and we'll talk about how to do that later. This is more just getting you into the mindset of testing React.