Automatic retry mechanism in Cypress - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the test result when Cypress retries a failing assertion?

Consider this Cypress test snippet that checks if a button is visible:

cy.get('#submit-btn').should('be.visible')

If the button is initially hidden but appears after 2 seconds, what will be the test result?

Cypress

cy.get('#submit-btn').should('be.visible')

A The test passes because Cypress retries until the button becomes visible within the default timeout.

B The test passes only if the button is visible at the exact moment of the first check.

C The test fails immediately because the button is hidden at first.

D The test throws an error because retries are not supported for visibility checks.

💡 Hint

Think about how Cypress handles assertions and retries automatically.

Cypress automatically retries assertions like should('be.visible') until they pass or timeout. So if the button appears within the timeout, the test passes.

❓ assertion

intermediate

Which assertion triggers Cypress automatic retry?

Which of the following assertions will Cypress automatically retry until it passes or times out?

A expect(element).to.equal(null)

B expect(element).to.exist

C expect(element).to.have.length(0)

D expect(element).to.throw()

💡 Hint

Consider which assertions Cypress retries when checking DOM elements.

Cypress retries assertions that check for existence or state of elements, like to.exist. Assertions like to.equal(null) or to.throw() are not retried automatically.

🔧 Debug

advanced

Why does this Cypress test fail despite automatic retries?

Review the following test code:

cy.get('#loading').should('not.exist')
cy.get('#content').should('be.visible')

The test fails because #loading still exists after timeout. Why might Cypress not retry the second assertion?

Cypress

cy.get('#loading').should('not.exist')
cy.get('#content').should('be.visible')

A Because <code>cy.get()</code> commands do not retry automatically.

B Because <code>should('not.exist')</code> does not support retries, so it fails immediately.

C Because Cypress retries only the first assertion and ignores the second one.

D Because the first assertion fails, Cypress stops and never retries the second assertion.

💡 Hint

Think about how Cypress handles test failures and command chaining.

If an assertion fails, Cypress stops the test immediately and does not continue to the next commands. So the second assertion is never retried.

❓ framework

advanced

How to customize retry behavior in Cypress tests?

Which option correctly sets Cypress to retry a failed test up to 3 times before marking it failed?

A In <code>cypress.config.js</code>, add <code>retries: { runMode: 3 }</code>

B Add <code>cy.retry(3)</code> inside the test block

C Use <code>cy.get().should('retry', 3)</code> on the element

D Set <code>testRetries = 3</code> in the test file

💡 Hint

Check Cypress official config options for retries.

Cypress supports retries configured globally or per test via retries in cypress.config.js. The other options are invalid commands or settings.

🧠 Conceptual

expert

What is the main benefit of Cypress automatic retry mechanism?

Why does Cypress automatically retry commands and assertions during test execution?

A To force tests to pass even if the application is broken.

B To increase test execution time by repeating commands unnecessarily.

C To reduce flaky test failures caused by temporary delays or slow UI updates.

D To avoid writing explicit wait commands in every test.

💡 Hint

Think about common problems in UI testing and how retries help.

Cypress retries help tests pass reliably by waiting for UI elements or states to stabilize, reducing flaky failures due to timing issues.