Why intercepting network validates API integration in Cypress - Framework Benefits

Framework Mode - Why intercepting network validates API integration

Folder Structure

cypress/
├── e2e/                  # Test specs
│   └── api_integration.cy.js
├── fixtures/             # Test data files
│   └── user.json
├── support/              # Custom commands and utilities
│   ├── commands.js
│   └── intercepts.js
cypress.config.js         # Cypress configuration file

Test Framework Layers

• Test Specs (e2e/): Contains test files that define the test scenarios using Cypress commands.
• Support Layer (support/): Holds reusable commands and intercept logic to mock or spy on network requests.
• Fixtures (fixtures/): Stores static test data used to simulate API responses.
• Configuration (cypress.config.js): Manages environment settings like base URLs and timeouts.

Configuration Patterns

Use cypress.config.js to set base URLs for different environments (dev, staging, prod). Use environment variables to switch API endpoints or credentials without changing test code.

import { defineConfig } from 'cypress';

export default defineConfig({
  e2e: {
    baseUrl: 'https://api.example.com',
    env: {
      apiKey: 'test-api-key',
      environment: 'staging'
    },
    setupNodeEvents(on, config) {
      // setup code
    }
  }
})

Fixtures provide mock data for API responses to test different scenarios reliably.

Test Reporting and CI/CD Integration

Use Cypress built-in reporters or plugins like mochawesome to generate readable test reports showing which API calls passed or failed.

Integrate Cypress tests into CI/CD pipelines (GitHub Actions, Jenkins) to run API integration tests automatically on code changes.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: cypress-io/github-action@v5
        with:
          start: npm start
          wait-on: 'http://localhost:3000'
          wait-on-timeout: 60

Framework Design Principles

• Use Network Interception to Spy and Stub: Intercept API calls to verify requests are sent correctly and stub responses to test UI behavior without relying on real backend.
• Keep Tests Independent: Mock API responses so tests do not depend on external services, making them faster and more reliable.
• Use Fixtures for Consistent Data: Store expected API responses in fixtures to reuse and maintain test data easily.
• Validate Both Request and Response: Check that the app sends correct data and handles API responses properly.
• Integrate with CI/CD: Run API integration tests automatically to catch issues early.

Self Check

Where in this folder structure would you add a new intercept to mock the login API response?

Answer: Add the intercept logic in cypress/support/intercepts.js and call it from your test spec in cypress/e2e/api_integration.cy.js.

Key Result

Intercepting network calls in Cypress allows validating API integration by spying on requests and stubbing responses to ensure correct communication between frontend and backend.

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