Retry-ability of commands in Cypress - Cheat Sheet & Quick Revision

Recall & Review

beginner

What does retry-ability mean in Cypress commands?

Retry-ability means Cypress automatically repeats a command until it passes or times out. This helps tests wait for elements or conditions to be ready without manual waits.

beginner

Which Cypress commands are retry-able by default?

Commands like get(), contains(), should(), and find() are retry-able. Cypress keeps trying them until the element appears or the assertion passes.

beginner

Why is retry-ability helpful in testing dynamic web pages?

Because web pages can load elements slowly or change over time, retry-ability lets tests wait for the right state without failing immediately. It makes tests more stable and less flaky.

intermediate

How long does Cypress retry a command before failing?

Cypress retries commands up to the default timeout of 4 seconds. You can change this timeout if needed. If the command still fails after this time, the test fails.

intermediate

Can you disable retry-ability for a Cypress command?

No, retry-ability is built into Cypress commands and cannot be disabled. But you can control timeouts or use commands that do not retry, like then().

What happens when a retry-able Cypress command fails initially?

A Cypress retries the command until it passes or times out

B The test immediately fails

C Cypress skips the command

D The command runs only once more

Cypress automatically retries retry-able commands until they pass or the timeout is reached.

Which of these Cypress commands is NOT retry-able?

A contains()

B should()

C get()

D then()

then() does not retry because it runs after commands resolve.

How can you change how long Cypress retries a command?

A By disabling retry-ability

B By using a different command

C By setting a custom timeout option

D By restarting the test

You can set a custom timeout to control how long Cypress retries commands before failing.

Why is retry-ability important for testing web pages?

A It makes tests faster

B It helps tests wait for elements to appear

C It disables assertions

D It skips slow tests

Retry-ability helps tests wait for elements or conditions to be ready, improving stability.

If a retry-able command never passes, what happens?

A The test fails after timeout

B The command is skipped

C The test passes anyway

D The test pauses indefinitely

If the command does not pass before the timeout, Cypress fails the test.

Explain retry-ability in Cypress and why it helps make tests more reliable.

Think about how Cypress handles commands that don't succeed immediately.

Describe how you can control the retry timeout in Cypress and when you might want to adjust it.

Consider scenarios with slow or fast loading elements.

Practice

1. What does retry-ability in Cypress help with during test execution?

easy

A. Automatically waiting for elements or conditions before proceeding

B. Skipping tests that take too long to run

C. Running tests in parallel on multiple browsers

D. Generating test data automatically

Solution

1. Step 1: Understand retry-ability concept

   Retry-ability means Cypress waits and retries commands until the element or condition is met or timeout occurs.

2. Step 2: Identify what retry-ability helps with

   This automatic waiting avoids flaky tests caused by timing issues, ensuring tests proceed only when ready.

3. Final Answer:

   Automatically waiting for elements or conditions before proceeding -> Option A

4. Quick Check:

   Retry-ability = Automatic wait [OK]

Hint: Retry-ability means Cypress waits automatically for conditions [OK]

Common Mistakes:

• Confusing retry-ability with parallel test execution
• Thinking retry-ability skips tests
• Assuming retry-ability generates test data

2. Which of the following Cypress command patterns correctly uses retry-ability?

easy

A. cy.wait(5000).get('.btn').click()

B. cy.get('.btn').click()

C. cy.click('.btn')

D. cy.get('.btn').should('be.visible').click()

Solution

1. Step 1: Identify retry-ability usage

   Retry-ability works with commands like get combined with should assertions that retry until condition is true.

2. Step 2: Check each option

   cy.get('.btn').should('be.visible').click() uses get with should('be.visible') which retries until the button is visible before clicking.

3. Final Answer:

   cy.get('.btn').should('be.visible').click() -> Option D

4. Quick Check:

   Use get + should for retry-ability [OK]

Hint: Use get() with should() for retry-ability in Cypress [OK]

Common Mistakes:

• Using cy.click() directly without get()
• Relying on fixed wait times instead of should()
• Missing should() causes no retry

3. Consider this Cypress code snippet:

cy.get('#status').should('contain', 'Success')
cy.get('#submit').click()

What happens if the element with id status initially does not contain 'Success' but updates after 2 seconds?

medium

A. The test fails immediately because 'Success' is not found

B. The test skips the assertion and clicks submit immediately

C. Cypress retries the assertion until 'Success' appears or timeout

D. The test waits 2 seconds automatically before clicking submit

Solution

1. Step 1: Understand retry-ability with should()

   The should('contain', 'Success') assertion retries until the text appears or timeout.

2. Step 2: Analyze behavior when text updates after 2 seconds

   Cypress waits and retries the assertion, so it passes once 'Success' appears, then proceeds to click.

3. Final Answer:

   Cypress retries the assertion until 'Success' appears or timeout -> Option C

4. Quick Check:

   should() retries until condition met [OK]

Hint: should() retries assertions until success or timeout [OK]

Common Mistakes:

• Assuming test fails immediately without retry
• Thinking Cypress waits fixed time automatically
• Believing test skips assertion

4. You wrote this Cypress test:

cy.get('.loading').should('not.exist')
cy.get('.content').click()

But the test fails because .content is not clickable yet. What is the likely cause?

medium

A. The get('.content') command does not wait for element to be clickable

B. The should('not.exist') does not retry properly for .loading

C. You need to add wait() before clicking .content

D. The selector .content is incorrect

Solution

1. Step 1: Understand retry-ability of should('not.exist')

   The should('not.exist') retries until the loading element disappears, so this part works correctly.

2. Step 2: Analyze get('.content').click() behavior

   The get command retries until the element exists but does not wait for it to be clickable or visible before clicking.

3. Final Answer:

   The get('.content') command does not wait for element to be clickable -> Option A

4. Quick Check:

   get() waits for existence, not clickability [OK]

Hint: get() waits for element existence, not clickability [OK]

Common Mistakes:

• Assuming should('not.exist') fails to retry
• Adding unnecessary fixed waits
• Blaming wrong selector without checking

5. You want to test a button that appears only after a loading spinner disappears. Which Cypress command sequence best uses retry-ability to ensure the button is clicked only when ready?

hard

A. cy.get('.spinner').should('not.exist')
cy.get('button#submit').click()

B. cy.get('.spinner').should('not.exist')
cy.get('button#submit').should('be.visible').click()

C. cy.get('button#submit').should('be.visible').click()

D. cy.wait(3000)
cy.get('button#submit').click()

Solution

1. Step 1: Wait for spinner to disappear

   Using should('not.exist') on spinner retries until spinner is gone, ensuring loading finished.

2. Step 2: Wait for button to be visible before clicking

   Using should('be.visible') retries until button is visible and ready for click, avoiding flaky clicks.

3. Final Answer:

   cy.get('.spinner').should('not.exist') cy.get('button#submit').should('be.visible').click() -> Option B

4. Quick Check:

   Chain should() assertions for reliable waits [OK]

Hint: Chain should('not.exist') and should('be.visible') for reliable clicks [OK]

Common Mistakes:

• Clicking button immediately after spinner disappears without visibility check
• Using fixed wait instead of retry-ability
• Skipping spinner wait and causing flaky tests