cypress
cypress copied to clipboard
cypress-io
`cy.tick(n)` does not wait for Promises to resolve during the tick; has to be called twice - expose more lolex methods on cy.clock
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 call cy.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:
- Clone https://github.com/isaaclyman/cypress-test-tiny/tree/double-timeout-test
-
npm install,npm run cypress:open, click the first test file - Observe that the first test fails and the second test passes
Test code:
app.js:
var getPromise = () => new Promise((resolve, reject) => {
setTimeout(resolve, 100)
})
setTimeout(() => {
getPromise().then(() => setTimeout(() => {
document.getElementById('main').innerHTML = 'Loaded!'
}, 100))
}, 100)
spec.js:
describe('page', () => {
beforeEach(() => {
cy.clock()
cy.visit('index.html')
})
// This test fails
it('loads with a single tick', () => {
cy.tick(2000)
cy.get('#main').contains('Loaded').should('exist')
})
// This test passes
it('loads with a double tick', () => {
cy.tick(1000)
cy.tick(1000)
cy.get('#main').contains('Loaded').should('exist')
})
})
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.
- Operating System: Windows 10
- Cypress Version: 1.4.2
- Browser Version: Chrome 64
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.
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.