Now that we have learned about intercepting API calls, we can move on to the next concept, and that is stubbing.
In simple terms, this means that we can take any API call and instead of getting a real server response, we provide our frontend with our own. So, for example, this get-api-boards, which will load all of the boards when the application is loaded, has a list of all of the boards that are in the database.
So in here you can see that it is an array of objects that's going to contain all of the data about a certain board. So we can see attributes like start, false, we can see the name, which is shopping, the id, and created date, and also the user. These are some real data that are in our database.
We can check that by going to database.json, and here we can see an array with a single board that has exactly the same attributes as we see here. Let's now, instead of the real response, provide our own. To do that, I'm going to add another argument into my intercept command. The first object defines what API call we want to match, and the second one defines how we want to handle it. So, for example, we can change the body and instead of array of objects, we'll provide an empty array.
When I now save my test, you'll see that my application behaves as if there were no boards in my database. However, when I look into my database, I can still see the shopping. So right now, my application is not showing the real data, but the data that I have provided within my test. We can take it a little bit further and create our own response. So let's say we give this a name tau, start attribute of true, id of 11, user 0, and created date will be 20, 23, 11, 03. And I'll add a comma because I forgot one. When I now save my test, I can see my tau board. I'll see that it is start, but of course, if I click on it, I'm going to get an error because this board does not really exist.
It has an id of 11, and in my database, I have no such board. So instead of real data, I'm providing fake data. When I open a board, there's an API call for a board with the id of 11. Since that does not exist, we get an error. This stubbing is really useful if we want to get to some edge cases in our application.
For example, if I want to check an empty state, I don't have to delete all of my boards from the database. I can just stub this API endpoint that requests all of the boards and make sure everything looks all right. Or if I want to create my own data, I can do that. Now, instead of defining every board on my own, I can use another attribute, which is called fixture. This attribute will look for a file in our fixtures folder where I have stored a two boards.json. It is again an array of objects with the name Rick and Morty and with some crazy IDs. If I provide the name to boards.json and save my test, I can see now that the list of my boards is Rick and Morty.
Stubbing can be very useful if we want to test for some edge cases. For example, in this test, we want to make sure that an error message shows when there's a problem with creating a board. Users should see that something is happening. So in here, I'm intercepting the post API boards, which is the API call that's made when we create a new board. And then I visit my home page, create a new board, click on create new board button, type the name of the board and hit enter. In my intercept, I'm going to add another object and I'm going to define a status code.
Let's say, let's say that's going to be 500. And as soon as I save my test, I can see, I can see that the API endpoint returned 500. When I hover over this API endpoint, I can find this error message. And since Cypress creates snapshots, I can easily just go ahead and target this message, copy that to my test and assert that this message is visible.
When I now save my test, I can see that the message has appeared and my test is passing. This use case would be really hard to get to, but with stubbing, we can get to it easily.