Why Automatic retry mechanism in Cypress? - Purpose & Use Cases

The Big Idea

What if your tests could fix themselves when things go wrong, without you lifting a finger?

The Scenario

Imagine you are testing a website manually. Sometimes, a button click does not work because the page is still loading or a network delay happens. You try clicking again and again, hoping it will work. This wastes time and causes frustration.

The Problem

Manual retry is slow and unreliable. You might miss errors or give up too soon. It is easy to forget to retry or retry too many times. This leads to flaky tests and wasted effort.

The Solution

An automatic retry mechanism in Cypress tries the action again and again until it succeeds or a timeout happens. It saves you from writing extra code and makes tests stable and fast.

Before vs After

✗ Before

cy.get('button').click()
// If fails, manually add retry logic

✓ After

cy.get('button').click()
// Cypress retries automatically until success or timeout

What It Enables

Automatic retries let your tests handle delays and temporary failures smoothly, making testing faster and more reliable.

Real Life Example

When testing a login form, the submit button might be disabled until all fields are filled. Automatic retry waits and clicks only when the button is ready, avoiding test failures.

Key Takeaways

Manual retries are slow and error-prone.

Automatic retry mechanism retries actions until success or timeout.

This makes tests stable, faster, and easier to write.

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