Automatic retry mechanism in Cypress - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of the automatic retry mechanism in Cypress?

It helps Cypress automatically retry commands and assertions until they pass or a timeout occurs, making tests more stable and reliable.

beginner

Which Cypress commands benefit from automatic retries?

Commands like cy.get(), cy.contains(), and assertions such as should() are automatically retried until they pass or timeout.

intermediate

How does Cypress decide when to stop retrying a command?

Cypress stops retrying when the command or assertion passes or when the default timeout (usually 4 seconds) is reached.

intermediate

How can you customize the retry timeout in Cypress?

You can set a custom timeout by passing the { timeout: milliseconds } option to commands, for example: cy.get('.btn', { timeout: 10000 }) retries for 10 seconds.

beginner

Why is automatic retry better than adding manual waits in tests?

Automatic retry waits only as long as needed for the condition to pass, making tests faster and less flaky compared to fixed manual waits.

What happens if a Cypress command fails initially?

A The test immediately fails without retrying.

B Cypress retries the command until it passes or times out.

C Cypress skips the command and continues.

D The test pauses and waits for manual input.

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

Which of these commands does Cypress retry automatically?

A cy.task()

B cy.log()

C cy.exec()

D cy.get()

cy.get() is retried automatically; commands like cy.log() do not retry.

How can you increase the retry timeout for a specific command?

A By adding <code>{ timeout: value }</code> option to the command

B By changing the global Cypress config only

C By adding <code>cy.wait()</code> before the command

D By disabling retries in Cypress

You can pass a timeout option directly to commands to customize retry duration.

What is the default timeout for retries in Cypress?

A 4 seconds

B 10 seconds

C 1 second

D No timeout, retries forever

By default, Cypress retries commands for up to 4 seconds before failing.

Why should you avoid using fixed waits instead of relying on automatic retries?

A Fixed waits are required for retries to work.

B Fixed waits make tests faster.

C Fixed waits slow down tests and can cause flakiness.

D Automatic retries do not work with dynamic content.

Fixed waits add unnecessary delay and can cause flaky tests; automatic retries wait only as long as needed.

Explain how Cypress automatic retry mechanism improves test reliability.

Think about how waiting for elements or conditions works in real life.

Describe how to customize retry timeout for a Cypress command and why you might do it.

Consider a slow website or network delay scenario.

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