How to Intercept and Mock Network Requests in Cypress? - 面试题

In modern frontend automated testing, Cypress, as a popular end-to-end testing framework, offers powerful capabilities for intercepting and mocking network requests, which are key to enhancing test reliability and efficiency. When testing applications that involve API calls, real network requests may be affected by external factors (such as network latency or server unavailability), leading to unstable test results. By intercepting and mocking network requests, developers can precisely control the test environment, validate component behavior under different response scenarios, and ensure application robustness. This article will delve into Cypress's intercept method, providing practical guidance from fundamentals to advanced techniques to help you build more reliable test suites.

Basic Concepts

Cypress's intercept feature allows you to dynamically intercept HTTP/HTTPS requests during test execution and mock responses or modify request content. This is based on Cypress interceptors (Interceptor) mechanism, which operates within the test's virtual environment, avoiding browser-level network dependencies to ensure test isolation. The core principles are:

Interceptor Registration: Register interception rules in your test scripts using cy.intercept().
Request Handling: Define request matching rules (e.g., URL, method, parameters) and return mocked responses.
Test Control: Use methods like cy.wait() to wait for specific interception events and validate request behavior.

Key advantages include:

Isolation: No need for real network access, avoiding external dependencies.
Flexibility: Mock various responses (success, error, delay).
Maintainability: Decouple test logic from actual API implementations.

Note: Cypress interceptors only affect requests during test execution and do not impact the browser's actual behavior. Ensure the test environment is properly configured to avoid conflicts with real services.

Practical Steps

1. Basic Interception and Response Mocking

The simplest scenario involves intercepting a GET request and returning a fixed response. The following code demonstrates how to mock an API response in a test:

javascript
// In the test file
it('Mock successful response', () => {
  // Register interceptor: matches '/api/data' GET requests
  cy.intercept('GET', '/api/data').as('get-data');

  // Trigger request (e.g., click a button)
  cy.get('.fetch-button').click();

  // Wait for interception event to complete
  cy.wait('@get-data').then((interception) => {
    // Validate response status and data
    expect(interception.response.statusCode).to.equal(200);
    expect(interception.response.body.data).to.equal('mocked');
  });
});

Parameter Explanation:
- 'GET': Request method (replace with 'POST', 'PUT', etc.).
- '/'api/data': URL pattern (supports wildcards, e.g., /api/*).
- .as('get-data'): Name the interceptor for later waiting.
Key Point: Using .as() is crucial for waiting; avoid confusion with undefined interceptors when using cy.wait().

2. Mocking Errors and Delayed Responses

Mocking error responses (e.g., 500 status code) or delayed requests is critical for testing failure scenarios. For example:

javascript
// Mock 500 error
cy.intercept('GET', '/api/error').as('error-call');

// Mock 2000ms delay
cy.intercept('GET', '/api/delay').delay(2000);

// Validate error response
cy.get('.error-text').should('be.visible').and('contain', 'API failed');

Advanced Usage: Use respond() to customize responses:

javascript
cy.intercept('GET', '/api/custom').respond({ status: 201, body: { success: true } });

Important Note: When mocking errors, ensure test logic captures exceptions (e.g., using try/catch or assertions).

3. Handling Dynamic Requests and Parameters

When APIs depend on dynamic parameters, such as query strings, use wildcards for matching:

javascript
// Matches all '/api/users' requests (with parameters)
 cy.intercept('GET', '/api/users').as('users-fetch');

 // Mock response with parameters (e.g., '/api/users?filter=active')
 cy.intercept('GET', '/api/users').respond((req) => {
   return { status: 200, body: { data: req.query.filter } };
 });

Best Practices:
- Use req.url to retrieve the original URL and parse parameters.
- Generate mock data for tests (e.g., req.query).
- Avoid hardcoding parameters to improve test reusability.

4. Advanced Techniques: Redirection and Request Chains

In complex scenarios, such as API redirection or chained requests, Cypress provides onRequest and onResponse callbacks:

javascript
// Intercept and handle redirection
 cy.intercept('GET', '/api/redirect').as('redirect-call');
 cy.intercept('GET', '/api/redirect', (req) => {
   req.on('response', (res) => {
     if (res.statusCode === 301) {
       // Mock redirection to new URL
       req.continue(() => res.set('Location', '/api/redirected')); 
     }
   });
 });

Key Recommendations:
- Prioritize chained calls (e.g., .as() + .wait()) for clarity.
- For large-scale tests, combine Cypress route API to manage multiple interceptors.
- Avoid modifying request bodies in interceptors to maintain test isolation.

Common Issues and Solutions

Issue 1: Interceptors Not Working

Cause: URL mismatch (e.g., case sensitivity) or incorrect test execution order.
Solution:
- Use wildcards: '/api/*' to match all subpaths.
- Debug: Add console.log(req.url) to confirm requests.
- Refer to Cypress Official Documentation.

Issue 2: Real Network Interfering Tests

Cause: Test environment not isolated, real requests overriding mocks.
Solution:
- Use networkStub configuration when calling cy.visit().
- Disable browser network via Cypress.automation('network-stub') (only during tests).
- Keep the test environment clean: clear interceptors after each test (cy.intercept().reset()).

Issue 3: Inaccurate Response Delays

Cause: delay() not applied correctly or browser caching affecting results.
Solution:
- Use cy.intercept().as() combined with cy.wait() to ensure order.
- For complex scenarios, prefer respond() over delay().
- Disable caching before tests: cy.visit('/test', { cache: false }).

Conclusion

Cypress's network request interception and mocking capabilities are invaluable tools for frontend testing, significantly improving test coverage and stability. Through this article's steps, you've mastered practical techniques from basic response mocking to handling dynamic parameters and error scenarios. The key is integrating interceptors into your test workflow—ensuring each test case defines explicit request behavior and using cy.wait() for precise control. We recommend following these principles in real projects:

Test-Driven Development: Design test scenarios first, then implement interception logic.
Version Control: Include interceptor configurations in test scripts for traceability.
Continuous Integration: Enable interceptors in CI/CD pipelines to prevent real network interference.

Final Recommendation: Cypress interceptors are not a replacement for real APIs but a powerful supplement for testing. Always combine manual testing for critical paths and refer to Cypress Official Guide for deeper learning. Mastering these techniques will help you build more robust and maintainable frontend test suites.

Appendix: Practical Code Snippets

Mocking Authenticated Requests

javascript
cy.intercept('GET', '/api/secure').as('secure-call');
cy.request('/api/secure', { headers: { 'Authorization': 'Bearer token' } });
cy.wait('@secure-call').then(interception => {
  expect(interception.response.body).to.have.property('user');
});

Global Interceptor Configuration (in cypress/support/index.js)

javascript
// Automatically handle all API requests
Cypress.on('window:load', () => {
  cy.intercept('GET', '/api/*').as('api');
});

Avoid Common Pitfalls:
- Do not overuse cy.intercept() in tests; reserve it for testing scenarios only.
- Name each interceptor to avoid conflicts.
- Use cy.log('Request: ', req.url) for debugging.

Figure: Visual example of network request interception in Cypress tests (source: Cypress Official Documentation)