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.

Practice

1. What does Cypress's automatic retry mechanism do during test execution?

easy

A. It requires manual loops to retry commands.

B. It skips failed tests automatically without retrying.

C. It keeps trying commands and assertions until they pass or timeout.

D. It only retries tests when explicitly told by the user.

Solution

1. Step 1: Understand Cypress retry behavior

   Cypress automatically retries commands and assertions until they pass or the timeout is reached.

2. Step 2: Compare options with this behavior

   Only the option stating "It keeps trying commands and assertions until they pass or timeout." correctly describes this automatic retry mechanism without manual intervention.

3. Final Answer:

   It keeps trying commands and assertions until they pass or timeout. -> Option C

4. Quick Check:

   Automatic retry = keeps trying until pass [OK]

Hint: Remember: Cypress retries commands/assertions automatically [OK]

Common Mistakes:

• Thinking retries happen only on user command
• Believing Cypress skips failed tests without retry
• Assuming manual loops are needed for retries

2. Which of the following is the correct syntax to assert that an element with id submit-btn is visible, leveraging Cypress's automatic retry?

easy

A. cy.get('#submit-btn').assertVisible()

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

C. cy.find('#submit-btn').should('visible')

D. cy.getElement('#submit-btn').isVisible()

Solution

1. Step 1: Identify correct Cypress command and assertion

   The correct command to select an element is cy.get() and the assertion to check visibility is should('be.visible').

2. Step 2: Validate syntax correctness

   cy.get('#submit-btn').should('be.visible') uses the correct syntax and leverages automatic retry on the assertion. Other options use invalid commands or incorrect assertion syntax.

3. Final Answer:

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

4. Quick Check:

   Correct syntax = cy.get + should('be.visible') [OK]

Hint: Use cy.get() with should() for retries on assertions [OK]

Common Mistakes:

• Using non-existent commands like assertVisible()
• Incorrect assertion strings like 'visible' instead of 'be.visible'
• Using cy.find() instead of cy.get()

3. Consider the following Cypress test code:

cy.get('.loading').should('not.exist')
cy.get('#data').should('contain', 'Success')

What will happen if the element with class loading disappears after 3 seconds but the default timeout is 4 seconds?

medium

A. The test will fail immediately because the element exists at first.

B. The test will pass only if manual wait is added before assertions.

C. The test will timeout and fail because Cypress does not retry on should('not.exist').

D. The test will pass because Cypress retries until the element disappears within timeout.

Solution

1. Step 1: Understand retry on should('not.exist')

   Cypress automatically retries assertions like should('not.exist') until the element disappears or timeout.

2. Step 2: Analyze timing and retry behavior

   The element disappears after 3 seconds, which is before the 4-second timeout, so the assertion will eventually pass.

3. Final Answer:

   The test will pass because Cypress retries until the element disappears within timeout. -> Option D

4. Quick Check:

   Retry waits for condition until timeout [OK]

Hint: Remember: should('not.exist') retries until element gone [OK]

Common Mistakes:

• Assuming immediate failure if element exists initially
• Believing manual waits are always needed
• Thinking Cypress does not retry negative assertions

4. You wrote this Cypress test:

cy.get('#submit').click()
cy.get('#result').should('contain', 'Done')

But the test fails because #result text updates slowly. Which fix uses Cypress's automatic retry correctly?

medium

A. Use cy.get('#result', { timeout: 7000 }).should('contain', 'Done') to increase timeout.

B. Change to cy.get('#result').should('contain', 'Done') as is (no change).

C. Replace should with then for immediate check.

D. Add cy.wait(5000) before the assertion.

Solution

1. Step 1: Identify problem with slow update

   The element #result updates slowly, so default timeout may be too short.

2. Step 2: Use automatic retry with increased timeout

   Use cy.get('#result', { timeout: 7000 }).should('contain', 'Done') to increase the timeout, letting Cypress retry the assertion longer until it passes.

3. Final Answer:

   Use cy.get('#result', { timeout: 7000 }).should('contain', 'Done') -> Option A

4. Quick Check:

   Increase timeout to let retry succeed [OK]

Hint: Increase timeout to extend retry duration [OK]

Common Mistakes:

• Using fixed waits instead of timeout options
• Not changing anything and expecting success
• Replacing should with then, which disables retry

5. You want to test a button that becomes enabled only after an API call completes. The button has id submit-btn. Which Cypress code best uses automatic retry to wait for the button to be enabled before clicking it?

hard

A. cy.get('#submit-btn').should('be.enabled').click()

B. cy.get('#submit-btn').click()

C. cy.wait(3000); cy.get('#submit-btn').click()

D. cy.get('#submit-btn').then($btn => { if ($btn.is(':enabled')) { $btn.click() } })

Solution

1. Step 1: Understand button enabling timing

   The button becomes enabled after an API call, so it may be disabled initially.

2. Step 2: Use automatic retry on enabled state

   cy.get('#submit-btn').should('be.enabled').click() uses should('be.enabled') which retries until the button is enabled, then clicks it.

3. Final Answer:

   cy.get('#submit-btn').should('be.enabled').click() -> Option A

4. Quick Check:

   Use should('be.enabled') to wait before click [OK]

Hint: Chain should('be.enabled') before click to wait [OK]

Common Mistakes:

• Clicking immediately without waiting
• Using fixed wait instead of retry
• Using then() which disables retry and may fail