Fixtures

[00:00:00]
>> So we looked at how to make requests. I guess the other part is like how to stub responses, right? And we kind of saw that before and it's not particularly surprising, right. Like we can either give it a JavaScript object or we can reference a fixture right?

[00:00:21]
So if we think about for instance like bring me to the correct Pokemon. I could theoretically say not only do I want the API but no matter what we want all if it's a list. I just want make sure that you took whatever was from the response and put it on the page as you were supposed to.

[00:00:43]
I don't even need real data for this. I'm like cool, just you took what was in that JSON page load, you did whatever formatting you needed to do. It got onto the page the way it was supposed to, right. I can actually, I don't necessarily need a real server for that, right?

[00:00:58]
Get what you were supposed to get as long as it adheres to the contract, and we should be okay. So let's do it in this one, maybe. So it should render results to the page, right? And so in this case, I might choose to have one where it's like, I don't know.

[00:01:18]
So we'll say, so I've just called stubbed API at this point because I need to name stuff. Where I might say, Pokemon search. Slash API question mark star where it's got the actual query params. And it could be in the body. You could do it all sorts of different ways.

[00:01:44]
And we'll just take that array of Pokemon that we had up there. And that will now be whenever we hit this endpoint which will say, as stubbed, we will get back this response no matter what. I don't need that API server to be running. It might not be something I control.

[00:02:09]
Might not be something that I can hit from my CICD. Whatever it is like cool intercepted and hit the request and send me back this response. So then with that in place we'll go find that search. And we'll type in something. We've already have a different test to make sure we're sending the right payload, right.

[00:02:31]
Now we're trying to make sure that we've triggered it. And we're doing the right thing when whatever comes back, right. So they're slightly isolated from each other, but that's totally fine in my opinion. And so it was which spring into the route or have the correct Pokemon. Let's see.

[00:02:54]
How do I wanna deal with this? Should render results to the page. Like I should probably see if there's three of the things in my mock data. What are these? You can actually see that it's my mock data, right? Cuz I stubbed it in this case and that's the last test.

[00:03:15]
It is the fake Bumblesaur charmer and turtle, cuz I couldn't come up with a clever name. So I can do results has a length of three. So it actually I sent you back three responses, you rendered through the page. I can verify that the first one is the first one, so on and so forth.

[00:03:34]
But the other interesting part is, there was no alias set on that intercept. But this little empty dot here, instead of the solid green dot that we had in the previous test means that it never went through. Means that we intercepted it, stopped it from going through. And now we put in our own response, as you can see in this case.

[00:03:55]
And you can see it on the page as well. So we can kind of go in there and get our own individual ones. Cool, now save it. So you can see it was called stabbed. I just didn't save the file before. But that empty circle means the fact that it was in fact stubbed, Mark.

[00:04:13]
>> In what case should you use contains versus should contain [INAUDIBLE].
>> You can probably just use contains a lot of cases. I think if I knew it was gonna stop it contains, a lot of times I might, if I'm gonna use an end or something along those lines.

[00:04:27]
I think the should still lets me do an end or have other assertions on it contains is not it's gonna give me a different result of the chain. I'm pretty sure. If it's like stopping out with just a contains I usually like this comes down to personal preference to be really honest.

[00:04:45]
It's about what am I intending, right. If it's a one liner test or something that is on the page I get that by reading it. It helps me know that this was my thought at the time. It comes down to simply my opinion personal preference So ,we've got that typed in there.

[00:05:06]
We can see that it's stubbed now and we get that response coming back no matter what, right. The other option is, we'll go ahead and say hey, if they go get poking on number one. And this is now mostly just demonstrate. So, if they go to get number one I could use a regex as well for this.

[00:05:26]
And make sure it was a number that we wanna give them back, actually a fixture around Bulbasaur. But we'll say, if they're go looking for that, this is a demonstrate how you would use a fixture more than anything else. Can simply type fixture and then Bulbasaur. And why this works is that they have a file in the fixtures directory named Bulbasaur dot JSON.

[00:05:55]
So there's no importing the file. You could also just do an import JSON with common JS and ES modules. Definitely common JS, that thing's obstructed probably as modules. We should fact check that. But, with the fixture, we'll go read that JSON file. And automatically put it back in place.

[00:06:17]
So I could say I'm gonna intercept that. And we'll say as Bulbasaur fixture just to demonstrate. And then what was a code results So what is this first one? I don't really wanna do that. So we'll do results. Not gonna take a suggestion in this case. Because that autogenerated class is not helping me.

[00:06:49]
We'll say results A, got the first one. And click on it You can see that it filled in that fixture data, right? So you can put in a JavaScript object, you can have a fixture. If the data is large you almost always want a fixture. If it's real small, it's kind of up to you.

[00:07:13]
You could also see a world. Like one of the things that I want to build that we have not built yet is like we have a bunch of fixtures for temporal that actually set the server up in different ways. What I really wanna do is have a weekly thing that basically updates our fixtures based on real data.

[00:07:30]
So we're kind of like if something changes are fixtures change. Where I could see myself basically having a Node script hitting the API requests. Dumping those JSON files into a folder in my Cypress like directory. And so I'm working with relatively like real data. And so if the data changes I have new fixtures which is something you could not do if you had just an object in your code, right.

[00:07:55]
So that's another part of what do you use when that is maybe better than if big put in JSON file. If small put away you can see it. Is like there are pieces around a fixture, right. The hard part though is like if you actually care about that data, you're not gonna get as much auto like IntelliSense as if it was a JavaScript object in the file.

[00:08:17]
So it's a trade off. And it's just JavaScript trade offs and not Cypress trade offs. So you have a bunch of ways to kind of mock in there. And again, you'll see that if you code it with a stub, that you get that kind of hollowed out circle versus if it was just something that you watched.

[00:08:33]
If I take off the only on here, we should see a bunch of the other tests. Wait for those to run. If it went through solid green done. If you stubbed it out or I'm sorry, if you stopped the response then you'll get a hollow.to signify that did not go all the way through to the server.

[00:08:53]
But you also get to see all the URL changes, and all the fetches and get that kind of step by step view of your code as you go through.