cy.wait() for explicit waiting in Cypress - Build an Automation Script

Verify explicit wait using cy.wait() before checking element visibility

Preconditions (2)

Step 1: Open the URL 'https://example.com/delayed-message'

Step 2: Click the button with id 'show-message-btn'

Step 3: Wait explicitly for 3 seconds using cy.wait()

Step 4: Verify that the element with id 'delayed-message' is visible and contains text 'Hello after wait!'

✅ Expected Result: After clicking the button and waiting explicitly, the delayed message appears and is visible with correct text

Automation Requirements - Cypress

Assertions Needed:

Verify element with id 'delayed-message' is visible

Verify element text equals 'Hello after wait!'

Best Practices:

Use cy.wait() only when necessary for explicit waiting

Use cy.get() with proper selectors

Use assertions with .should() for visibility and text

Avoid arbitrary waits longer than needed

Automated Solution

Cypress

describe('Explicit wait test with cy.wait()', () => {
  it('Waits explicitly before checking delayed message', () => {
    cy.visit('https://example.com/delayed-message');
    cy.get('#show-message-btn').click();
    cy.wait(3000); // wait for 3 seconds explicitly
    cy.get('#delayed-message')
      .should('be.visible')
      .and('have.text', 'Hello after wait!');
  });
});

This test opens the page, clicks the button to trigger a delayed message, then uses cy.wait(3000) to pause the test for 3 seconds explicitly. After waiting, it checks that the message element is visible and contains the expected text. Using cy.wait() here simulates waiting for an asynchronous event that takes time to complete.

We use cy.get() with id selectors for clarity and reliability. Assertions use .should() chaining to verify visibility and text content. This approach ensures the test waits exactly as needed before checking the result.

Common Mistakes - 3 Pitfalls

Using cy.wait() with too long or arbitrary time without reason

Not using cy.get() with proper selectors before assertions

{'mistake': 'Using cy.wait() instead of waiting for element visibility', 'why_bad': 'Waiting fixed time may fail if element appears sooner or later, causing flaky tests', 'correct_approach': "Prefer commands like cy.get().should('be.visible') which wait automatically for elements"}

Bonus Challenge

Now add data-driven testing with 3 different wait times: 1000ms, 2000ms, and 3000ms, verifying the message appears correctly each time

Show Hint

Practice

1. What is the main purpose of using cy.wait() in Cypress tests?

easy

A. To pause the test for a specific time or until a request finishes

B. To skip a test step temporarily

C. To restart the test from the beginning

D. To automatically retry failed assertions

Solution

1. Step 1: Understand the function of cy.wait()

   cy.wait() is used to pause the test execution either for a fixed time or until a network request completes.

2. Step 2: Compare with other options

   Skipping steps, restarting tests, or retrying assertions are not functions of cy.wait().

3. Final Answer:

   To pause the test for a specific time or until a request finishes -> Option A

4. Quick Check:

   Pause test = cy.wait() [OK]

Hint: Remember: cy.wait() pauses test execution explicitly [OK]

Common Mistakes:

• Thinking cy.wait() skips test steps
• Confusing cy.wait() with test retries
• Assuming cy.wait() restarts tests

2. Which of the following is the correct syntax to wait explicitly for 3 seconds in Cypress?

easy

A. cy.wait(3s)

B. cy.wait('3000')

C. cy.wait(3)

D. cy.wait(3000)

Solution

1. Step 1: Check the correct argument type for cy.wait()

   The argument must be a number representing milliseconds, so 3000 means 3 seconds.

2. Step 2: Validate each option

   cy.wait(3000) uses a number 3000 correctly. cy.wait('3000') uses a string which is invalid. cy.wait(3) uses 3 which means 3 milliseconds, not 3 seconds. cy.wait(3s) uses an invalid unit '3s'.

3. Final Answer:

   cy.wait(3000) -> Option D

4. Quick Check:

   Milliseconds number = cy.wait(3000) [OK]

Hint: Use milliseconds as number, no quotes or units [OK]

Common Mistakes:

• Passing time as string instead of number
• Using seconds instead of milliseconds
• Adding units like 's' inside wait argument

3. Consider this Cypress code snippet:

cy.intercept('GET', '/api/data').as('getData')
cy.visit('/dashboard')
cy.wait('@getData')
cy.get('#result').should('be.visible')

What will cy.wait('@getData') do here?

medium

A. Pause test until the GET request to '/api/data' finishes

B. Pause test for 1 second regardless of request

C. Immediately continue without waiting

D. Cause a syntax error because of wrong alias

Solution

1. Step 1: Understand alias usage with cy.wait()

   The alias '@getData' refers to the intercepted GET request to '/api/data'. Using cy.wait('@getData') waits for that request to complete.

2. Step 2: Check other options

   It does not wait a fixed time (not 1 second), nor does it continue immediately. The alias is correctly defined, so no syntax error.

3. Final Answer:

   Pause test until the GET request to '/api/data' finishes -> Option A

4. Quick Check:

   Wait for request alias = cy.wait('@getData') [OK]

Hint: Wait for alias pauses until that request finishes [OK]

Common Mistakes:

• Confusing alias wait with fixed time wait
• Assuming immediate continuation
• Mistaking alias syntax causing errors

4. You wrote this Cypress code:

cy.wait(5000)
cy.get('.submit-btn').click()

But the test fails because the button is not clickable after 5 seconds. What is the likely problem?

medium

A. The selector '.submit-btn' is invalid syntax

B. The wait time 5000 is too long and causes timeout

C. Using fixed wait instead of waiting for the button to be ready

D. cy.wait() cannot be used before cy.get()

Solution

1. Step 1: Analyze the use of fixed wait

   Waiting a fixed 5 seconds does not guarantee the button is ready or clickable. The button might appear later or be disabled.

2. Step 2: Consider better waiting strategy

   Better to wait for the button to exist or be enabled using assertions or wait for network requests instead of fixed time.

3. Final Answer:

   Using fixed wait instead of waiting for the button to be ready -> Option C

4. Quick Check:

   Fixed wait ≠ reliable readiness [OK]

Hint: Wait for element readiness, not fixed time [OK]

Common Mistakes:

• Assuming fixed wait always works
• Blaming selector syntax without checking
• Thinking cy.wait() must come after cy.get()

5. You want to wait for two different API calls to finish before checking the page content. Which code correctly waits for both requests using cy.wait()?

hard

A. cy.wait('@apiCall1', '@apiCall2')

B. cy.wait('@apiCall1'); cy.wait('@apiCall2')

C. cy.wait(['@apiCall1', '@apiCall2'])

D. cy.wait('@apiCall1') && cy.wait('@apiCall2')

Solution

1. Step 1: Understand how to wait for multiple aliases

   Cypress requires chaining cy.wait() calls sequentially for different aliases to ensure both requests complete.

2. Step 2: Evaluate each option

   cy.wait('@apiCall1'); cy.wait('@apiCall2') correctly chains the waits using semicolon separation, which queues them in Cypress. cy.wait('@apiCall1', '@apiCall2') passes multiple arguments incorrectly. cy.wait('@apiCall1') && cy.wait('@apiCall2') uses logical AND which does not chain Cypress commands properly. cy.wait(['@apiCall1', '@apiCall2']) uses an unsupported array argument.

3. Final Answer:

   cy.wait('@apiCall1'); cy.wait('@apiCall2') -> Option B

4. Quick Check:

   Chained waits = cy.wait('@apiCall1'); cy.wait('@apiCall2') [OK]

Hint: Chain cy.wait() calls for multiple aliases [OK]

Common Mistakes:

• Passing multiple aliases as separate arguments
• Using && instead of proper chaining
• Using unsupported array of aliases