You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cypress v6.2.1 using cy.intercept to send a static response. My goal is to clearly see the loading indicator in the UI, thus I want to slow down the server response.
Situation
Without intercept, the request fires 3 seconds after the page loads
it('use positive then negative assertion',()=>{cy.visit('/?delay=3000')// first, make sure the loading indicator shows up (positive assertion)cy.get('.loading').should('be.visible')// then assert it goes away (negative assertion)cy.get('.loading').should('not.be.visible')})
Notice how quickly the loading message appears and disappears without network control. In fact it passes on the first run, and fails to "catch" the quickly appearing loading element on the second re-run.
loading.mp4
Of course, this is a flakey test and we could use test retries to solve it. But let's make the test better using network control.
Attempt
So I want to slow down the network request to GET /todos to always have the loading indicator stay visible for a period of time.
it('slows down the network response (does not work)',()=>{cy.intercept('/todos',{body: [],delayMs: 2000})cy.visit('/?delay=3000')// first, make sure the loading indicator shows up (positive assertion)cy.get('.loading').should('be.visible')// then assert it goes away (negative assertion)cy.get('.loading').should('not.be.visible')})
Hmm, it looks wrong! It looks like the delayMs wasn't even applied
Ok, let's see. If our application makes the request after 3 seconds, let's set the response to be sent after 5 seconds
delay-5.mp4
yeah, this works, but is so counterintuitive
Workaround
Use programmatic reply and not a static response
it('slows down the network response (programmatic)',()=>{cy.intercept('/todos',req=>{req.reply({body: [],delayMs: 2000})})cy.visit('/?delay=3000')// first, make sure the loading indicator shows up (positive assertion)cy.get('.loading').should('be.visible')// then assert it goes away (negative assertion)cy.get('.loading').should('not.be.visible')})
BUT this solution also has a bug noted in #14446 - it uses the first time req.reply runs to "remember" the response delay :)
Desired output
when using static intercept, start counting the delay from the moment the network request starts
The text was updated successfully, but these errors were encountered:
The code for this is done in cypress-io/cypress#14708, but has yet to be released.
We'll update this issue and reference the changelog when it's released.
Cypress v6.2.1 using
cy.intercept
to send a static response. My goal is to clearly see the loading indicator in the UI, thus I want to slow down the server response.Situation
Without intercept, the request fires 3 seconds after the page loads
Notice how quickly the loading message appears and disappears without network control. In fact it passes on the first run, and fails to "catch" the quickly appearing loading element on the second re-run.
loading.mp4
Of course, this is a flakey test and we could use test retries to solve it. But let's make the test better using network control.
Attempt
So I want to slow down the network request to
GET /todos
to always have the loading indicator stay visible for a period of time.Hmm, it looks wrong! It looks like the
delayMs
wasn't even applieddelay-not-applied.mp4
Code
Looking at the code in
cypress/packages/driver/src/cy/net-stubbing/static-response-utils.ts
Line 106 in f43f1c1
I see that we compute the response time using the time when
cy.intercept()
command runsOk, let's see. If our application makes the request after 3 seconds, let's set the response to be sent after 5 seconds
delay-5.mp4
yeah, this works, but is so counterintuitive
Workaround
Use programmatic reply and not a static response
BUT this solution also has a bug noted in #14446 - it uses the first time
req.reply
runs to "remember" the response delay :)Desired output
when using static intercept, start counting the delay from the moment the network request starts
The text was updated successfully, but these errors were encountered: