YAML
---
name: implementing-test-pyramid
description: Implements the test pyramid strategy with unit tests at the base, integration in the middle, and E2E at the top. Use when designing test suites, planning testing strategy, or explaining test distribution rationale.
---

Implementing Test Pyramid Strategy

Python
# Test distribution following pyramid principle
# Unit tests (70-80%): Fast, isolated, numerous
def test_calculate_discount():
    assert calculate_discount(100, 0.1) == 10

# Integration tests (15-25%): Module interactions
def test_payment_service_integration():
    payment_service = PaymentService(mock_gateway)
    result = payment_service.process_payment(valid_card, 100)
    assert result.success

# E2E tests (5-10%): Full user journeys
def test_complete_purchase_flow():
    browser.goto("/products")
    browser.click("[data-testid=add-to-cart]")
    browser.fill("[data-testid=checkout-form]", payment_data)
    assert "Order confirmed" in browser.text_content("h1")

Progress:

• Identify components to test
• Write unit tests first (aim for 70-80% coverage)
• Add integration tests for critical interactions (15-25%)
• Create minimal E2E tests for key user flows (5-10%)
• Validate pyramid shape in CI metrics

1. Start with Unit Tests

   • Test individual functions/methods in isolation
   • Mock external dependencies
   • Aim for millisecond execution times

2. Add Integration Tests

   • Test module boundaries and data flow
   • Use real databases/services when possible
   • Focus on critical business logic interactions

3. Minimize E2E Tests

   • Test complete user journeys end-to-end
   • Cover happy path and critical error scenarios only
   • Run against production-like environments

4. Monitor Test Health

   • Track execution times and failure rates
   • Maintain pyramid ratios in CI dashboards
   • Refactor slow tests down the pyramid when possible

Example 1: E-commerce Test Distribution

E2E (5%): Complete purchase, user registration
Integration (20%): Payment processing, inventory updates  
Unit (75%): Price calculations, validation logic, formatters

Example 2: API Service Testing

E2E (8%): Full request/response cycles with real database
Integration (22%): Database queries, external API calls
Unit (70%): Business logic, data transformations, utilities

• Write unit tests first - They're fastest to implement and debug
• Keep E2E tests stable - Flaky E2E tests block deployments
• Use test doubles appropriately - Mocks for unit, real services for integration
• Optimize for feedback speed - Unit tests should run in seconds
• Focus E2E on user value - Test what users actually do
• Measure and maintain ratios - Use CI metrics to track pyramid health

• Inverted pyramid - Too many E2E tests, too few unit tests
• Testing implementation details - Unit tests coupled to internal structure
• Slow unit tests - Database calls or network requests in unit tests
• Brittle E2E tests - Testing edge cases that should be unit tested
• Missing integration layer - Jumping from units directly to E2E
• Not failing fast - Running expensive tests before cheap ones fail