Why intercepting network validates API integration in Cypress - Quick Recap

Recall & Review

beginner

What does intercepting network requests in Cypress help verify?

It helps verify that the frontend correctly sends requests and handles responses from the backend API, ensuring proper API integration.

intermediate

How does intercepting network requests improve test reliability?

By controlling or observing API responses, tests can run consistently without depending on real backend availability or data changes.

beginner

What Cypress command is used to intercept network calls?

The cy.intercept() command is used to spy on or stub network requests and responses.

beginner

Why is validating API integration important in end-to-end tests?

It ensures the frontend and backend communicate correctly, preventing bugs caused by mismatched data or failed requests.

intermediate

What is a key benefit of stubbing API responses during tests?

It allows testing frontend behavior under different API response scenarios, like errors or slow responses, without changing backend code.

Which Cypress command is used to intercept network requests?

A cy.route()

B cy.request()

C cy.visit()

D cy.intercept()

cy.intercept() is the modern command to intercept network requests in Cypress. cy.route() is deprecated.

Why intercept network requests in API integration tests?

A To verify frontend-backend communication

B To speed up UI rendering

C To change CSS styles

D To test database queries

Intercepting network requests helps verify that the frontend sends and receives correct API data.

What is a benefit of stubbing API responses in tests?

A Control test scenarios without backend changes

B Make tests slower

C Hide UI elements

D Change user permissions

Stubbing lets you simulate different API responses to test frontend behavior reliably.

Intercepting network requests helps tests to be:

A Dependent on backend uptime

B More reliable and consistent

C Slower to run

D Only UI focused

Intercepting allows tests to run without relying on real backend, improving reliability.

Which is NOT a reason to intercept network calls in Cypress?

A To validate API integration

B To stub responses for error testing

C To modify CSS styles dynamically

D To spy on request data

Intercepting network calls does not affect CSS styling.

Explain how intercepting network requests in Cypress helps validate API integration.

Think about how frontend and backend talk during tests.

Describe the benefits of stubbing API responses during Cypress tests.

Consider why you might want to fake API answers.

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