Why intercepting network validates API integration in Cypress - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why does intercepting network requests help validate API integration?

When using Cypress to test a web app, why is intercepting network requests important for validating API integration?

A It speeds up the test execution by skipping the API calls entirely.

B It allows checking the exact request and response data exchanged with the API to ensure correct communication.

C It automatically fixes API errors during the test run.

D It hides the API calls from the browser console to reduce noise.

💡 Hint

Think about how you can confirm the app talks correctly to the backend.

Intercepting network requests lets you see the real data sent and received. This confirms the app and API work together as expected.

❓ Predict Output

intermediate

What is the test result when intercepting a GET API call?

Consider this Cypress test snippet that intercepts a GET request and checks the response status:

cy.intercept('GET', '/api/items', { statusCode: 200, body: [{ id: 1, name: 'Item1' }] }).as('getItems')
cy.visit('/items')
cy.wait('@getItems').its('response.statusCode').should('eq', 200)

What will be the test result?

A Test fails due to syntax error in intercept definition.

B Test fails because the intercepted response body is empty.

C Test fails with a timeout error waiting for '@getItems'.

D Test passes because the intercepted response status is 200 as asserted.

💡 Hint

Check the status code in the intercept and assertion.

The intercept mocks the GET /api/items call with a 200 status and a body. The test waits for this call and asserts the status code is 200, so it passes.

❓ assertion

advanced

Which assertion correctly verifies the API response body after intercept?

Given this intercepted API call in Cypress:

cy.intercept('POST', '/api/login', { statusCode: 200, body: { token: 'abc123' } }).as('login')

Which assertion correctly checks that the response body contains the token 'abc123'?

A cy.wait('@login').its('response.body.token').should('eq', 'abc123')

B cy.wait('@login').should('have.property', 'token', 'abc123')

C cy.get('@login').should('contain', 'abc123')

D cy.wait('@login').its('request.body.token').should('eq', 'abc123')

💡 Hint

Remember to check the response body, not the request body.

Option A correctly waits for the alias, accesses the response body token, and asserts its value. Others either check wrong properties or use invalid commands.

🔧 Debug

advanced

Why does this Cypress intercept test fail with a timeout?

Look at this Cypress test code:

cy.intercept('GET', '/api/data').as('getData')
cy.visit('/dashboard')
cy.wait('@getData').its('response.statusCode').should('eq', 200)

The test fails with a timeout waiting for '@getData'. What is the most likely reason?

A The assertion is wrong because response.statusCode is not accessible.

B The intercept syntax is incorrect and causes the test to crash.

C The app does not make a GET request to '/api/data' during the visit, so the alias is never triggered.

D The cy.visit() command blocks network requests until complete.

💡 Hint

Think about whether the app triggers the expected API call.

If the app never calls the GET /api/data endpoint during the visit, the alias '@getData' is never triggered, causing cy.wait to timeout.

❓ framework

expert

How does Cypress intercept improve API integration test reliability?

In what way does using Cypress's network intercept feature improve the reliability of API integration tests compared to relying on live API calls?

A It allows tests to run with controlled, predictable API responses, avoiding flakiness from network issues or backend changes.

B It automatically retries failed API calls until they succeed, ensuring test passes.

C It disables all API calls so tests run faster without backend dependencies.

D It records API calls for playback in production environments.

💡 Hint

Consider how controlling API responses affects test stability.

Intercepting network calls lets tests use fixed responses, so tests don't fail due to slow or changing backend behavior, making them more reliable.

Practice

1. Why is intercepting network calls important in Cypress tests for API integration?

easy

A. It automatically fixes API errors during tests.

B. It speeds up the UI rendering by skipping API calls.

C. It allows verifying that the app sends correct requests and handles responses properly.

D. It disables the network to prevent any API communication.

Solution

1. Step 1: Understand intercept purpose

   Intercepting network calls lets tests watch and control API requests and responses.

2. Step 2: Connect intercept to validation

   This helps confirm the app sends correct data and reacts properly to API replies.

3. Final Answer:

   It allows verifying that the app sends correct requests and handles responses properly. -> Option C

4. Quick Check:

   Intercept = Verify API communication [OK]

Hint: Intercept checks requests and responses to validate API [OK]

Common Mistakes:

• Thinking intercept speeds UI rendering
• Believing intercept fixes API errors automatically
• Assuming intercept disables all network calls

2. Which is the correct Cypress command syntax to intercept a GET request to '/api/users'?

easy

A. cy.intercept('GET', '/api/users')

B. cy.intercept('/api/users', 'GET')

C. cy.route('GET', '/api/users')

D. cy.interceptGet('/api/users')

Solution

1. Step 1: Recall Cypress intercept syntax

   The correct syntax is cy.intercept(method, url) where method is 'GET' and url is '/api/users'.

2. Step 2: Compare options

   cy.interceptGet('/api/users') uses a non-existent command. cy.intercept('/api/users', 'GET') reverses parameters. cy.route('GET', '/api/users') uses deprecated cy.route. cy.intercept('GET', '/api/users') matches the correct syntax.

3. Final Answer:

   cy.intercept('GET', '/api/users') -> Option A

4. Quick Check:

   cy.intercept(method, url) = correct syntax [OK]

Hint: Use cy.intercept('METHOD', 'URL') format [OK]

Common Mistakes:

• Swapping method and URL parameters
• Using deprecated cy.route instead of cy.intercept
• Using non-existent commands like cy.interceptGet

3. Given this Cypress test code, what will be the assertion result?

cy.intercept('GET', '/api/data', { fixture: 'data.json' }).as('getData');
cy.visit('/dashboard');
cy.wait('@getData').its('response.statusCode').should('eq', 200);

medium

A. The test will fail because fixture responses have no status code.

B. The test will pass because the intercepted response status is 200.

C. The test will error due to missing cy.intercept alias.

D. The test will timeout waiting for '@getData'.

Solution

1. Step 1: Analyze intercept with fixture

   Using a fixture returns a mocked response with status code 200 by default.

2. Step 2: Check wait and assertion

   cy.wait('@getData') waits for the intercepted call, then asserts response.statusCode equals 200, which is true.

3. Final Answer:

   The test will pass because the intercepted response status is 200. -> Option B

4. Quick Check:

   Fixture response status = 200 [OK]

Hint: Fixture responses default to status 200 unless overridden [OK]

Common Mistakes:

• Assuming fixture responses lack status codes
• Forgetting to alias intercept for cy.wait
• Expecting real network calls instead of mocked

4. Identify the error in this Cypress test code that intercepts a POST request:

cy.intercept('POST', '/api/login', (req) => {
  req.reply({ statusCode: 201, body: { success: true } });
}).as('login');
cy.visit('/login');
cy.get('button[type=submit]').click();
cy.wait('@login').its('response.statusCode').should('eq', 201);

medium

A. The intercept is missing an alias '@login' for cy.wait.

B. The reply status code 201 is invalid for POST requests.

C. The cy.get selector is incorrect for the submit button.

D. The intercept callback should not use req.reply.

Solution

1. Step 1: Check intercept alias usage

   The intercept does not have an alias set with .as('login'), so cy.wait('@login') will fail.

2. Step 2: Verify other parts

   Status code 201 is valid for POST creation. The selector and req.reply usage are correct.

3. Final Answer:

   The intercept is missing an alias '@login' for cy.wait. -> Option A

4. Quick Check:

   Missing .as('login') causes cy.wait failure [OK]

Hint: Always alias intercept to use cy.wait('@alias') [OK]

Common Mistakes:

• Not adding .as() alias to intercept
• Confusing valid HTTP status codes
• Misunderstanding req.reply usage

5. You want to test how your app handles a slow API response using Cypress intercept. Which approach correctly simulates a 2-second delay on a GET request to '/api/items' and verifies the UI shows a loading spinner during the wait?

hard

A. Use cy.intercept('GET', '/api/items', (req) => { req.on('response', (res) => { res.setDelay(2000); }); }).as('getItems');
Then check spinner visibility before cy.wait('@getItems').

B. Use cy.intercept('GET', '/api/items').as('getItems');
Then use cy.wait(2000) before checking spinner visibility.

C. Use cy.intercept('GET', '/api/items', (req) => { req.delay(2000); }).as('getItems');
Then check spinner visibility after cy.wait('@getItems').

D. Use cy.intercept('GET', '/api/items', { delay: 2000 }).as('getItems');
Then check spinner visibility before cy.wait('@getItems').

Solution

1. Step 1: Simulate delay correctly in intercept

   Using { delay: 2000 } as the static route handler correctly adds a 2-second delay to the response.

2. Step 2: Verify spinner visibility timing

   Check the loading spinner is visible before waiting for the delayed response to finish with cy.wait('@getItems').

3. Final Answer:

   Use cy.intercept('GET', '/api/items', { delay: 2000 }).as('getItems'); Then check spinner visibility before cy.wait('@getItems'). -> Option D

4. Quick Check:

   { delay: 2000 } simulates slow response [OK]

Hint: Use { delay: 2000 } object in cy.intercept [OK]

Common Mistakes:

• Using invalid req.on('response', res => res.setDelay()) syntax
• Calling delay method directly on req
• Checking spinner only after wait instead of before