- 7Stub Network Requests in a Cypress Test3m 45s
Stub Network Requests in a Cypress Test
Share this video with your friends
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.
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?
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 :)
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.
seems cy.server is deprecated
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".