E2E testing specification

Code quality assurance is an indispensable part of frontend development, and E2E testing, as a critical method for validating system integrity, directly impacts user experience and business stability. A standardized E2E testing process can effectively reduce production defects and enhance team collaboration efficiency.

Core Objectives of E2E Testing

E2E testing needs to cover real user operation paths and validate the overall behavior of the system after module integration. It primarily focuses on three dimensions:

1. Business Process Validation: For example, the complete flow in an e-commerce scenario from login → product search → add to cart → payment → order generation.
2. Critical Interaction Verification: Such as form submissions, asynchronous loading, route navigation, and other high-frequency user operations.
3. Edge Case Coverage: Including network interruptions, API timeouts, data boundaries, and other non-standard scenarios.

// Typical e-commerce flow test example
describe('Checkout Flow', () => {
  it('should complete purchase', async () => {
    await loginWithTestAccount();
    await searchProduct('wireless headphones');
    await addToCart(0);
    await navigateToCheckout();
    await selectPayment('credit_card');
    await expect(orderConfirmation).toBeVisible();
  });
});

Test Environment Setup Standards

Tool Selection Criteria

• Cross-Browser Support: Prioritize solutions that support Chromium/WebKit/Firefox.
• Snapshot Comparison: Integrate visual regression testing tools like Percy.
• CI/CD Integration: Support for mainstream platforms (GitHub Actions/Jenkins, etc.).
• Debugging Friendliness: Generate video recordings and DOM snapshots upon failure.

Recommended tech stack:

1. Testing Framework: Cypress 10+ / Playwright
2. Assertion Library: Chai / Jest Expect
3. Mocking Service: MSW / Cypress intercept
4. Reporting System: Allure / ReportPortal

Environment Isolation Strategy

Test Case Design Principles

User Journey Modeling

Use Event Storming to identify critical paths:

1. Draw user operation sequence diagrams.
2. Mark system state transition points.
3. Identify third-party dependency nodes.

graph TD
    A[Visit Homepage] --> B[Search Product]
    B --> C{Results Page}
    C -->|In Stock| D[Add to Cart]
    C -->|Out of Stock| E[Show Out of Stock]
    D --> F[Checkout]

Data-Driven Practices

Parameterize tests using external data sources:

// fixtures/products.json
[
  { "name": "4K Monitor", "category": "electronics" },
  { "name": "Office Chair", "category": "furniture" }
]

// Test script
const testCases = require('./fixtures/products.json');

testCases.forEach((product) => {
  it(`should display ${product.name} correctly`, () => {
    // Test implementation...
  });
});

Execution and Maintenance Standards

Stability Assurance Measures

1. Smart Waiting Strategies:

// Anti-pattern - Fixed wait
cy.wait(5000);

// Recommended - Conditional wait
cy.get('[data-testid="checkout-btn"]', { timeout: 10000 })
  .should('be.visible');

2. Automatic Retry on Failure:

// cypress.json configuration
{
  "retries": {
    "runMode": 2,
    "openMode": 0
  }
}

Test Data Management

Use Factory pattern for test data:

class UserFactory {
  static create(overrides = {}) {
    const defaults = {
      name: 'test_user',
      email: `user_${Date.now()}@test.com`,
      tier: 'standard'
    };
    return { ...defaults, ...overrides };
  }
}

// Usage example
const premiumUser = UserFactory.create({ tier: 'premium' });

Quality Metrics System

Establish a test health dashboard to monitor key metrics:

// Metric calculation example
const calculateCoverage = () => {
  const criticalPaths = ['/checkout', '/account'];
  const testedPaths = getTestedRoutes();
  return (testedPaths.filter(p => criticalPaths.includes(p)).length / criticalPaths.length;
};

Key metric thresholds:

• Critical path coverage ≥ 95%
• Unexpected error rate < 0.5%
• Average execution time < 15 minutes/full suite

Team Collaboration Guidelines

Code Review Checklist

1. Test Description Standards:

   • Use Given-When-Then format.
   • Avoid technical jargon in behavior descriptions.

   // Non-compliant
   it('tests the API response', () => {...});
   
   // Compliant
   it('should display error when inventory is empty', () => {...});
   

2. Element Locator Rules:

   • Avoid CSS/XPath selectors.
   • Use data-testid attributes uniformly.

   <!-- Anti-pattern -->
   <button class="btn-primary">Submit</button>
   
   <!-- Recommended -->
   <button data-testid="order-submit">Submit</button>
   

Documentation Requirements

Maintain living documentation:

## Test Suite Structure
└── tests/
    ├── smoke/       # Smoke tests
    ├── regression/  # Regression tests
    └── visual/      # Visual tests

## Naming Convention
[type].[module].spec.js
Example: checkout.payment.spec.js

Continuous Improvement Mechanism

Establish a Test Debt tracking system:

// Tech debt tagging example
describe('Legacy Checkout', () => {
  // @tech-debt Needs migration to new payment gateway
  it.skip('processes credit card payment', () => {
    // Legacy implementation...
  });
});

Conduct regular test effectiveness audits:

1. Analyze defect escape rate.
2. Evaluate false positive/negative ratios.
3. Review test maintenance costs.