Cypress: `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

Created on 7 Feb 2018  路  5Comments  路  Source: cypress-io/cypress

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:

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
proposal 馃挕

Most helpful comment

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
})

All 5 comments

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.

Was this page helpful?
0 / 5 - 0 ratings