Testing Patterns Skill

Provide expert guidance on software testing strategies, patterns, and best practices.

When to Apply

Activate when the user:

• Asks about testing strategies or approaches
• Needs help writing unit, integration, or E2E tests
• Wants to improve test coverage
• Asks about mocking, stubbing, or test fixtures
• Discusses test-driven development (TDD)
• Needs help with testing frameworks

Testing Pyramid

Follow the testing pyramid for balanced coverage:

        ╱╲        E2E Tests (10%)
       ╱  ╲       - User flows, critical paths
      ╱────╲
     ╱      ╲     Integration Tests (20%)
    ╱        ╲    - Component interaction, APIs
   ╱──────────╲
  ╱            ╲  Unit Tests (70%)
 ╱              ╲ - Functions, classes, modules
╱────────────────╲

Unit Testing Patterns

Arrange-Act-Assert (AAA)

describe('calculateTotal', () => {
  it('should apply discount correctly', () => {
    // Arrange
    const items = [{ price: 100 }, { price: 50 }];
    const discount = 0.1;

    // Act
    const total = calculateTotal(items, discount);

    // Assert
    expect(total).toBe(135);
  });
});

Test Naming Convention

Use descriptive names that explain the scenario:

• should_[expected behavior]_when_[condition]
• [method]_[scenario]_[expectedResult]

Edge Cases to Always Test

1. Empty inputs (null, undefined, [], '')
2. Boundary values (min, max, zero)
3. Invalid inputs (wrong types, malformed data)
4. Error conditions (network failures, timeouts)
5. Race conditions (async operations)

Integration Testing Patterns

Component Integration

describe('AuthService + SessionStore', () => {
  it('should persist session after successful login', async () => {
    const authService = new AuthService();
    const sessionStore = new SessionStore();

    await authService.login('user@example.com', 'password');

    const session = sessionStore.getSession();
    expect(session).toBeDefined();
    expect(session.userId).toBe('user-123');
  });
});

API Integration

describe('API Integration', () => {
  it('should create and retrieve a user', async () => {
    // Create
    const created = await api.post('/users', { name: 'Test' });
    expect(created.status).toBe(201);

    // Retrieve
    const retrieved = await api.get(`/users/${created.data.id}`);
    expect(retrieved.data.name).toBe('Test');
  });
});

Mocking Strategies

When to Mock

• External services (APIs, databases)
• Time-dependent operations
• Random generators
• Expensive operations
• Side effects (emails, notifications)

When NOT to Mock

• Internal logic being tested
• Simple utility functions
• Anything that's fast and deterministic

Mock Patterns

// Jest mock
jest.mock('./emailService', () => ({
  sendEmail: jest.fn().mockResolvedValue({ sent: true })
}));

// Dependency injection
class UserService {
  constructor(private emailService: EmailService) {}

  async createUser(data) {
    const user = await this.save(data);
    await this.emailService.sendWelcome(user.email);
    return user;
  }
}

// In test:
const mockEmailService = { sendWelcome: jest.fn() };
const service = new UserService(mockEmailService);

Test Coverage Guidelines

Meaningful Coverage Targets

• Unit tests: 80%+ for business logic
• Integration tests: Cover all API endpoints
• E2E tests: Cover critical user journeys

Coverage Anti-Patterns

• Testing getters/setters for coverage numbers
• Testing framework code (React rendering, etc.)
• Writing tests after bugs without understanding root cause

E2E Testing Patterns

Page Object Pattern

class LoginPage {
  visit() {
    cy.visit('/login');
  }

  fillEmail(email: string) {
    cy.get('[data-testid="email"]').type(email);
  }

  fillPassword(password: string) {
    cy.get('[data-testid="password"]').type(password);
  }

  submit() {
    cy.get('[data-testid="submit"]').click();
  }
}

// In test:
const loginPage = new LoginPage();
loginPage.visit();
loginPage.fillEmail('user@example.com');
loginPage.fillPassword('password');
loginPage.submit();

Test Data Management

• Use factories for test data generation
• Clean up data after tests
• Use unique identifiers to prevent collisions
• Consider database snapshots for complex scenarios

Test-Driven Development (TDD)

Red-Green-Refactor Cycle

1. Red: Write a failing test
2. Green: Write minimum code to pass
3. Refactor: Improve code while keeping tests green

TDD Benefits

• Forces thinking about API design upfront
• Ensures testability
• Creates living documentation
• Prevents over-engineering

Common Testing Mistakes

1. Testing Implementation: Test behavior, not implementation details
2. Flaky Tests: Fix immediately, they erode trust
3. Slow Tests: Parallelize, mock expensive operations
4. Over-mocking: If everything is mocked, what are you testing?
5. Missing Error Cases: Happy path isn't enough
6. Coupled Tests: Each test should be independent

Framework-Specific Guidance

JavaScript/TypeScript

• Jest for unit/integration tests
• Playwright or Cypress for E2E
• React Testing Library for component tests

Python

• pytest for all test types
• pytest-asyncio for async code
• Hypothesis for property-based testing

Go

• Built-in testing package
• Testify for assertions
• httptest for HTTP handlers

Applying This Skill

When helping with testing:

1. Identify the test type needed (unit/integration/E2E)
2. Suggest appropriate patterns
3. Show concrete examples in the project's language
4. Consider the testing pyramid balance
5. Recommend coverage targets based on criticality