Why intercepting network validates API integration in Cypress - The Real Reasons

The Big Idea

What if you could catch hidden bugs in how your app talks to servers before users do?

The Scenario

Imagine testing a website that talks to many servers to get data. You click buttons and wait, but you don't know if the website really sent the right requests or got the right answers from the server.

You try to watch the network traffic by opening browser tools and checking each request manually.

The Problem

This manual way is slow and confusing. You might miss some requests or misunderstand what the server sent back. It's easy to make mistakes and hard to repeat the checks exactly the same way every time.

Also, if the server changes, you won't know right away if the website still works well with it.

The Solution

Intercepting network calls with Cypress lets you catch every request and response automatically. You can check if the website sends the right data and if the server replies correctly.

This makes testing fast, clear, and repeatable. You can even fake server answers to test how the website behaves in different situations.

Before vs After

✗ Before

Open browser DevTools > Click Network tab > Watch requests > Guess if correct

✓ After

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

What It Enables

It makes sure the website and server talk perfectly, catching problems early and saving lots of guesswork.

Real Life Example

For example, an online store uses API calls to get product info. Intercepting network lets testers confirm the store shows the right products and prices every time, even if the server changes.

Key Takeaways

Manual network checks are slow and error-prone.

Intercepting network calls automates and clarifies API testing.

This ensures smooth communication between website and server.

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