Check out a free preview of the full Testing Web Apps with Cypress course

The "Intercept Practice" Lesson is part of the full, Testing Web Apps with Cypress course featured in this preview video. Here's what you'd learn in this lesson:

Steve demonstrates a few additional network request test examples and allows some time for students to complete a few additional challenges.


Transcript from the "Intercept Practice" Lesson

>> Okay, so, your job now is to try a slightly different app that kind of takes a few of the things that we talked about and puts it in place. So we have another app that, again, make some network requests to honestly, it's a JSON file under the hood I'm not gonna lie to you.

But you can say how many facts that you want. I did not intend to make a pun, that you hit Fetch to get dog facts. I'm sorry, but then when I realized that I could have changed it, and I didn't. So, I guess I did intend to make a pun, depending on how you think about the time space continuum.

So you gotta go, it will load in a certain number of facts. This one also changes the title of the page. And so, if you wanna try the site title, see if it changes appropriately, you can do that, as well, but it pulls in a number of facts.

Now, this is randomizing it from a large JSON file. If you wanted to, you could theoretically create a picture where you're always gonna get the same facts and verify that your test. Always depends on the problem you're trying to solve, it doesn't really matter. In this case, you wanna make sure you got the right number, what the content is doesn't necessarily matter.

But maybe your current user, right? Is always the same user with the same kind of preferences or stuff along those lines. But it's a chance to kinda go in and solve some of the problems in there yourself. Ideally, when they click the button, we should go and make sure that the API request was made, right?

That's we saw that version of that in the last example. It's a little bit different this time, but we should adjust the amount when the select is changed. So, anything along those lines should show the correct number of facts, right? That could either be you testing the response, or you testing what's rendered on the page.

I'll kinda leave it to whichever one seems like a more interesting challenge to you. And that we've changed the title, the Clear button puts us back into this empty state that you can see, as well. Some different things to kinda try out depending on which problems like to show up in your code base, so, you kinda wanna simplified version to wrap your head around.

So, why don't you spend about five minutes playing around with that, and we'll do a few of the ones that interest you, together we'll kinda look through them, as well. So, a lot of these are kind of extended practice around some things we saw previously. The biggest difference, instead of typing, we are actively clicking to trigger the API fetch, but the end result is same, right?

We are stubbing it, or we're spying on it and making sure that, in fact, it was called, right? The empty state should no longer exist as soon as they've hit the button, right? These things that we're kinda trying to make sure of as we go through. If they click for, we want to, and there's I could probably simplify this one a little bit, too, with the its syntax that we saw before that I typed, as well.

Where we could even say, cy.wait on that API. Then or its, exactly what I did before, its('request.url'). And you kinda see what's really happening there. We know that the interception is the thing getting passed through. Its is calling just basically the same properties on a nested object that we would see in this case.

And we could say should contain, include, match, whatever you want. Write, as well. All right, these are basically, this is a little bit more explicit, but this is probably easier and cleaner to write, as well. Let's set that one only and see it kinda in action. So, we've got the dog facts in that case, all right, cool.

So, first one worked. Yeah, cuz it didn't fire again, cuz we didn't click the button twice. Right, so, you can see that gets called once, gets called the second time, but both things are effectively testing the same way. One of the questions before is, with selectors I know that contains will not pass it if doesn't contain it.

Actually I know that works with DOM elements, I don't really know if that works with just strings. So, let's find out together. Yeah, so, contains will kinda be a terminal one that you don't have to necessarily have the showed on it. If it's a select, if you're testing the DOM, but if we're getting an actual string going through, it's gonna go through the regular assertion process.

Which is, yeah, so we've learned that one together. I was just like, why do I always do it like this? Cuz I probably got bitten once in the very beginning, and then developed the muscle memory. And then since I forgot why I do it like I do it.

But now I relearned it, so did you. Cool, so, yeah, we can change the amount, we should get the right results. Again, testing the things that are kind of under our control. If you needed to really get the same logic as the server, I usually test the request to make sure it was the request.

I trust that the server is doing the right thing. I wanna make sure that I'm doing the right thing. Could you use that kind of function that takes the request and the response, and then slices it and implement your server logic again in your test suite? You could, all right, then is your test suite gonna need a test suite?

It is, right? And so, while there might be a part of your job is to resist the urge to do stuff like that. Because it feels good, but you're just moving the problem around in the sake of just trying to get to what feels like purity but might not actually be.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now