Why intercepting network validates API integration in Cypress - Automation Benefits in Action

Validate API integration by intercepting network requests

Preconditions (3)

Step 1: Open the web application page that triggers the API call

Step 2: Use Cypress to intercept the API network request

Step 3: Trigger the action in the UI that causes the API call

Step 4: Wait for the intercepted API request to complete

Step 5: Verify the API request URL and method are correct

Step 6: Verify the API response status code is 200

Step 7: Verify the API response body contains expected data

✅ Expected Result: The API call is intercepted successfully, and the request and response data match the expected values, confirming correct API integration.

Automation Requirements - Cypress

Assertions Needed:

Verify intercepted request URL matches expected endpoint

Verify HTTP method is correct (e.g., GET, POST)

Verify response status code is 200

Verify response body contains expected data fields

Best Practices:

Use cy.intercept() to stub or spy on network requests

Use aliases to wait for requests with cy.wait()

Avoid hardcoding full URLs; use relative paths or environment variables

Assert on both request and response to validate integration

Keep tests isolated and independent

Automated Solution

Cypress

describe('API Integration Validation via Network Interception', () => {
  it('should intercept API call and validate request and response', () => {
    // Intercept the API call and alias it
    cy.intercept('GET', '/api/data').as('getData');

    // Visit the page that triggers the API call
    cy.visit('/data-page');

    // Trigger the action that causes the API call
    cy.get('button#loadData').click();

    // Wait for the API call to complete
    cy.wait('@getData').then(({ request, response }) => {
      // Assert request URL and method
      expect(request.method).to.equal('GET');
      expect(request.url).to.include('/api/data');

      // Assert response status code
      expect(response.statusCode).to.equal(200);

      // Assert response body contains expected data
      expect(response.body).to.have.property('items').and.be.an('array');
      expect(response.body.items.length).to.be.greaterThan(0);
    });
  });
});

This Cypress test intercepts the API call to /api/data using cy.intercept() and assigns it an alias @getData. It then visits the page that triggers the API call and clicks the button to load data.

Using cy.wait('@getData'), the test waits for the API call to complete and accesses both the request and response objects.

Assertions check that the request method is GET and the URL contains the expected endpoint. It also verifies the response status code is 200, indicating success, and that the response body contains an items array with at least one element.

This approach validates that the frontend correctly integrates with the backend API by confirming the request is sent properly and the response data is as expected.

Common Mistakes - 4 Pitfalls

Not waiting for the intercepted request to complete before asserting

Hardcoding full URLs including domain in intercept

Only asserting on request or only on response

Using cy.route() instead of cy.intercept() in Cypress 6+

Bonus Challenge

Now add data-driven testing with 3 different API endpoints and verify each response

Show Hint

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