Article summary
Cypress integration testing is an important part of checking the overall health of a web app because it enables automated tests that consistently check if features across the app continue to work. An important part of testing is checking that the requests between the client and the server are succeeding as expected and that Cypress is giving enough time for each request to complete. You can achieve both of these goals using Cypress intercepts.
Setting Up the Intercept
The first step to setting up an intercept is declaring the server request Cypress should be listening for. The simplest way to do this is to call the cy.intercept function with a method and an endpoint like so:
cy.intercept("POST", "/app/admin/manage-users")
The created intercept will track requests sent to /app/admin/manage-users but not any of its subdomains. To also track requests from a given route’s subdomains add an * on the end of the route.
cy.intercept("POST", "/app/admin/manage-users*")
This can be useful if there are query or route parameters that change at runtime. Cypress is now listening for the requests, but to perform assertions on the result Cypress needs to store the results of the request into a variable. Adding an alias to the intercept statement above will enable the test to get the results of the request later.
cy.intercept("POST", "/app/admin/manage-users*").as(“user-update-request”)
Checking the Response
Aliases are Cypress’ way of storing information for use later in the test. The results of most Cypress functions can be stored by adding a .as(variable-name-here) to the end. Now that the results are being stored, the tests can make assertions about the responses. To do this, add a cy.wait(“variable-name-here”) after the user actions that generate the intercepted request.
// user finds and clicks save button
cy.wait(“user-update-request”)
Cypress will click the button and then wait for a save request afterward. To check the response that was received from the server, add a .then to the wait and then expect on the result. For example, we can check if the response code was a 200.
cy.wait(“user-update-request”).then((interception) => {
expect(interception.response?.statusCode).to.eq(200);
});
So, the complete setup and assertions will look like the following:
cy.intercept("POST", "/app/admin/manage-users*").as(“user-update-request”)
// user finds and clicks save button
cy.wait(“user-update-request”)
cy.wait(“user-update-request”).then((interception) =>
expect(interception.response?.statusCode).to.eq(200);
});
Intercepting requests like this enables more detailed checks on the traffic between the client and the server. A side effect is that Cypress will now wait for requests to finish before continuing with the test. This can be a way to guard against tests that fail intermittently. It is better to add a UI element that shows the status of long requests that the test can wait on because users in prod will also need to know when it is safe to navigate away from the page.
More on Intercepts
For more information on intercepting network requests in Cypress, check out their documentation on intercepts. It includes information about Cypress returning fake responses from requests, as well as instructions on more detailed test assertions.