Transcripted Summary
Cypress is a great tool even for API testing.
We've been looking at the API calls that our application is doing, but with Cypress we can even trigger our own API calls. For example, when I create a new board we can see that the post API boards called is being made. The post method is responsible for sending some data to the database.
So in my test I'm going to add a new command called cy.request. That's going to have a method of post, URL of API boards, and then the third argument is going to be the body. In the body we're sending the name attribute which will be the name of our board created via cy.request.
When I now save my test I can see my created via cy.request board appear. All of the APIs are different so it's good to take a look into the documentation to see what kind of methods, URLs, and payloads are supposed to work with your application and your API. But even if you don't have the documentation you can learn a lot by just taking a look at the application.
In Cypress we can see all of the XHR calls in the timeline panel. We can actually skip visiting our application altogether and create a pure API test. In my second test I'm going to call the same API call again and then use its command to look at the status and make sure that is equal to 201. When I run my test I can see that there's no UI being opened but everything is happening in the timeline.
Similar to cyintercept we have different ways of writing arguments in the request command. Instead of passing different properties we can pass an object where we can define a method, URL, and also different attributes. So for example if I want to add some headers I can do that by passing this headers attribute. My application needs this application JSON header whenever I need to get my data but usually headers might carry some metadata like authorization or some other information. If I want to do some more complex API testing I can use then command and then write my chai assertions. So for example I'm going to expect that the board's status is going to be equal to 200.
I can expect the board's body to have a certain length so let's say that's going to be 2 and I can examine so for example let's take the first one from the array and check that the id is a number. All of these assertions can be found in the documentation. I suggest you take a look at the assertions documentation and also at the documentation of the cy.request command.
I'll save my test now and now I can see it has actually failed because in my database I actually don't have two objects but I got four. This brings me to my final test. The reason why we may want to incorporate cy.request command into our end-to-end tests is to create a setup for our tests. For example in my application I have this post API endpoint which will reset the whole database. It's going to delete all of the data. Now of course this is usually not something that's available in production apps but it might serve as a representation for setting up data in the right way. Instead of having this as a test I can create a before hook that will be resetting my database before all of my tests. When I now save my test I start with a clean slate and then make my tests run.
Now all three tests are passing because I'm creating a first board, a second board and then finally I'm testing the boards that I have created. Normally in Cypress you should separate each and every it block so that the data does not overflow from one test to another but API tests are a little bit more forgiving for this pattern.
Just remember that this is the way how Cypress is designed. Every it block is a single test and it should normally not have side effects for any of the other tests.
Resources
- Docs for .request() command
- Article on why it is useful to skip UI and use API instead
- Article on API testing in Cypress
- Article on how to handle data from response
