Additional Resources and Q&A

[00:00:00]
>> Kent C. Dodds: So I'm gonna wrap this up with a couple of thoughts about the different levels of testing and general wrap up stuff. And then you can feel free to ask me any other questions. And we'll call it a day, okay? Cool, so who has heard of the testing pyramid?

[00:00:24]
All right so the testing pyramid's shaped like this, like a pyramid, right. So I should've had an example of this but you have at the bottom unit, then integration, and end to end. And the idea behind the testing pyramid is it should illustrate to you how much time you should be spending in each of these levels.

[00:00:49]
Well, I disagree with that. And here, actually the reasons why people say the testing pyramid is great. Because as you move from the bottom to the top things get to be more expensive from several standpoints. From maintainability and from how helpful the error messages are and how quick they can run.

[00:01:15]
And the resources required to run them, things like that. So it's a lot easier to set things up down here than up here. The other reason why they suggested testing trophy, is because they're a lot faster at the bottom, than to the top. Faster to right, faand faster to right.

[00:01:35]
So that's the justification for the testing pyramid, and when I look at that I see, okay, so the bottom is cheap and fast. Why don't I just do all of my tests at the bottom? Why, there's nothing here that says I should do anything at the top. If it's cheaper and faster that should always be the answer.

[00:01:57]
But the thing that the testing pyramid is missing, and why I created the testing trophy is something I call a confidence coefficient. So down here you can solve really simple problems, like flow will say, hey you're passing the variable 3. That's actually a string, it should be a number.

[00:02:17]
Or maybe your parameter should actually be a number and your function is messed up. So those are really easy problems to solve. But as you go up the testing trophy or the testing pyramid, the types of problems that you can solve with those things are really big. Like, hey, the checkout button doesn't work, you're losing money, fix that.

[00:02:39]
So the justification of spending most of my time with unit tests, I'm cool with unit tests, I think they're great. But by focusing most of my time down there, I could be missing out on catching some serious issues. And so the reason that I don't do everything with End to End is with these other two issues, they're kinda slow, and they're pretty expensive.

[00:03:08]
Luckily, we're getting tools that are making that a lot better. And so the top of this testing trophy is starting to get a little bit bigger for me. But integration tests are a really awesome place to get to where we can spend most of our time. We'll get most of our coverage from that in a way that doesn't take away from the speed at which we can run these or the cost from a maintenance.

[00:03:36]
Or even the resources to run them standpoint. So I actually have a whole talk that's kind of centered around this, that you can find at Search AS on their YouTube channel. Or actually you just go to kentcdodds.com/talks. And it is this one, write tests, not too many, mostly integration.

[00:04:02]
There's a link to the video there. So that's pretty much it, I've got a couple of interesting talks and links to other things, I also have a newsletter I send out every week. It's basically a blog post that's like 1000 words, it's not very long. Every single week and then two weeks later it'll hit my blog.

[00:04:28]
I got a lot of testing concepts on there too if you want to look into that.
>> Speaker 2: [INAUDIBLE]
>> Kent C. Dodds: Yeah I'm glad that this was asked. So we didn't really talk about end to end a whole lot. But one pattern that's really common in end to end tests is page object.

[00:04:45]
Where you create this object that serves a mechanism for selecting and clicking and updating input values and stuff like that for a specific page. The nice thing about that is it makes it really easy to pull up the settings page. And type in your username, your changed username, and click on the submit button or whatever.

[00:05:06]
So I actually really don't like the page objects pattern. And the reason why is because, to me, it illustrates that you are testing the same thing regularly. So if I need to select the same thing over and over then I'm probably going through the same process. Often what I'll see is somebody's writing an end to end test.

[00:05:31]
And we'll have one end to end test the user can register, and then they can check out. Or they can add an item to their cart and they can check out. And then they see the check out page. And then they have another one that the user can create an account, log in, go to their settings page.

[00:05:49]
And so you wind up testing the same page over and over again with this login screen. Where all you need is one task that can make sure a user can create an account. And then the rest of your test can hit the end point directly and say hey create me a new user and then you continue on with your test.

[00:06:06]
And so I think part of the reason why the tests are written in such a way necessitates the page object pattern is with the tools that we've had up to this point. Selenium kind of necessitates that because it's rendering in a totally separate context. You need to get those cookies in there somewhere somehow.

[00:06:25]
And so with Cyprus, your texts are actually running in the context of the browser, the same context that regular JavaScript is. So you can easily access local storage or do a whole bunch of stuff, so making those kinds of problems a lot less evident. And so I find the page object pattern is okay, it's fine.

[00:06:44]
But I find that I don't need it and if I'm using it, there's probably something I can do about my tests to make them better. Which at the end of the day will make them faster. So we were talking about the React testing library a little bit ago.

[00:07:01]
There is actually a cypress testing library that emulates the same kind of API. Where you can really easily select items within the page that allows you to kind of treat the page like a user would. You know, how does the user find the username field. Where do they look for the label that says username and fills out the field next to it.

[00:07:22]
So the way that it's written I don't think that I could get any value out of a page object because the test itself is, like the selectors are a lot more straightforward so. I don't really use the page object [INAUDIBLE].
>> Speaker 3: Test as documentation, [INAUDIBLE] riff on that.

[00:07:41]
>> Kent C. Dodds: Sure, tests on documentation. I've never really referenced tests as documentation because it normally doesn't bode well, it doesn't really work. So yeah, sometimes especially if you're doing like the BDD style, behavior driven development. Where like you have a project manager come in and say like right in English, this is what things should do.

[00:08:10]
And then you do this magic step to turn those things into tests, I could see that as kind of being a form of documentation. But most of the time, if I'm looking at a test suite for something, yeah, just doesn't make a whole lot of sense necessarily. Maybe I could see kind of some higher level tests that are literally only talking to the API, yeah.

[00:08:36]
But I've never really, I like the idea of tests as documentation but I never really rely on it because it's not really reliable. Most of the time when developers are creating tests they're not thinking about that as tests as documentation. So maybe you feel that way but your team will come and mess up all your documentation without knowing that.

[00:08:57]
So I suggest document it, and test it, and life's good. All righty, that´s it. Thank you all so much.
>> [APPLAUSE]