Stub Network Requests in a Cypress Test

InstructorAndy Van Slaars

Share this video with your friends

Send Tweet

To keep our tests fast and easily repeatable, it makes sense to create many integration tests and fewer full end-to-end tests. In this lesson, we’ll see how to stub out network requests to create repeatable integration tests by ensuring our application runs in a known state for our tests.

Ming Hann Voon
~ 5 years ago

What if after someone click on the check of an item? isn't it will make the test invalid as the shape of the GET is different?

Jacob Evans
~ 4 years ago

What if after someone click on the check of an item? isn't it will make the test invalid as the shape of the GET is different?

I am not 100% myself but I think that the test is just checking the stubbed data, ergo when he added a new todo which also changed the shape of the overall data that test was handling, it still passed. Please correct if I am off at all though Andy or anyone else :)

Andy Van Slaarsinstructor
~ 4 years ago

Right. We make assertions based on the stubbed data. We want known, reliable data to make assertions on and we're taking the actual server and data store out of the equation. What we're testing is that our UI shows what we expect based on known data. If we wanted to test for a different set of data (some checked, some not, all checked, etc.) we would setup a test with that server response mocked, then verify that our UI reflected that as expected.

Anthony
~ 4 years ago

seems cy.server is deprecated

Lucas Minter
~ 4 years ago

seems cy.server is deprecated

Yes it is! The cypress docs suggest using cy.intercept() instead. cy.server only intercepted XMLHttpRequests where cy.intercept "can intercept all types of network requests including Fetch API, page loads, XMLHttpRequests, resource loads, etc".