Open isaaclyman opened 6 years ago
cy.clock
and cy.tick
are wrappers around lolex: https://github.com/sinonjs/lolex
Lolex has a much broader API that has methods to make this easier. We should probably do a better job exposing all this to you.
Cypress calls into this file to instantiate the clock: https://github.com/cypress-io/cypress/blob/develop/packages/driver/src/cypress/clock.coffee
You likely need the details method to get access to lower level lolex methods like runAll
.
cy.clock().then((clock) => {
const methods = clock.details().methods
methods.runAll() // haven't tried this, maybe this works
})
or is there a way to use lolex directly in our tests instead of cypress clock ?
Sure, you can npm install
it and require/import it into your test and use it directly.
This code does not work btw:
cy.clock().then((clock) => {
const methods = clock.details().methods
methods.runAll() // haven't tried this, maybe this works
})
Confirmed the original test case still fails in 3.4.0 of Cypress
I think I'm having a similar problem when using React's useEffect
hook which schedules work after render -- the work I'm scheduling is also asynchronous using setTimeout
within a Promise.
No matter how many ticks()
I add, the timeout never seems to run -- debugging seems to show all the ticks have been 'applied' before the timeout is even created.
Still an issue in version 7 btw.
This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.
I am still encountering this issue. My workaround is to make Cypress wait for a millisecond before proceeding with the test.
cy.tick(n);
cy.wait(1);
cy.get('...').should('...');
This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.
Bump.
Current behavior:
When a
setTimeout
callback (or a debounced function, etc.) waits for a promise to resolve and then sets another timeout, you have to callcy.tick(n)
twice in order for the second callback to be reached, even if the delay on the tick would be sufficient to cover both timeouts.Desired behavior:
Cypress should wait for promises to resolve during a tick. Calling
cy.tick(n)
twice in a row should not be required; it's unintuitive and requires the Cypress tests to have an intimate knowledge of the inner workings of the app they are testing.If this is not fixable, the problem and workaround should be documented on this page.
How to reproduce:
npm install
,npm run cypress:open
, click the first test fileTest code:
app.js:
spec.js:
I apologize if this seems contrived. It was causing mysteriously failing tests on an actual project I'm working on, and it took me quite a while to determine the root cause. I don't believe it to be an unrealistic scenario in any complex app built with a modern framework.