Testing Strategies

Testing Strategies

Complete framework for building effective, maintainable test suites that give you confidence to ship.

When to Use

• Setting up testing for new projects
• Improving existing test coverage
• Practicing Test-Driven Development (TDD)
• Debugging flaky tests
• Deciding what to test (and what not to)
• Organizing test files and structure

Core Testing Principles

Test Behavior, Not Implementation:

• Test what the code does, not how
• Tests should survive refactoring
• Focus on public interfaces

Testing Pyramid:

         /\
        /  \         E2E (Few, slow, comprehensive)
       /----\
      /      \       Integration (Some, medium)
     /--------\
    /          \     Unit (Many, fast, isolated)
   /------------\

Write Tests That Fail Usefully:

• Clear error messages
• Pinpoint failure location
• Show expected vs actual

Workflow

Step 1: Choose the Right Test Level

Unit Tests (70% of tests):

WHEN TO USE:
- Business logic
- Data transformations
- Validation rules
- Pure functions
- Edge cases

CHARACTERISTICS:
- Fast (<100ms each)
- Isolated (no external dependencies)
- Many tests
- Run on every commit

Integration Tests (20% of tests):

WHEN TO USE:
- API endpoints
- Database operations
- External service integration
- Multiple components working together

CHARACTERISTICS:
- Medium speed (100ms-1s each)
- Real dependencies (test DB, APIs)
- Fewer than unit tests
- Run before merge

E2E Tests (10% of tests):

WHEN TO USE:
- Critical user journeys
- Complete workflows
- Cross-browser compatibility

CHARACTERISTICS:
- Slow (seconds per test)
- Full application stack
- Fewest tests
- Run before release

Step 2: Write Unit Tests (AAA Pattern)

Arrange-Act-Assert:

describe('UserService', () => {
  describe('createUser', () => {
    it('creates a user with valid data', async () => {
      // ARRANGE: Set up test data and dependencies
      const userData = {
        email: 'test@example.com',
        name: 'Test User'
      };
      const mockRepo = {
        save: jest.fn().mockResolvedValue({ id: '1', ...userData })
      };
      const service = new UserService(mockRepo);

      // ACT: Execute the code under test
      const result = await service.createUser(userData);

      // ASSERT: Verify the outcome
      expect(result).toEqual({ id: '1', ...userData });
      expect(mockRepo.save).toHaveBeenCalledWith(userData);
    });

    it('throws validation error for invalid email', async () => {
      // ARRANGE
      const userData = { email: 'invalid', name: 'Test' };
      const service = new UserService(mockRepo);

      // ACT & ASSERT
      await expect(service.createUser(userData))
        .rejects.toThrow('Invalid email format');
    });
  });
});

What to Unit Test:

✅ DO TEST:
- Business logic
- Data transformations
- Validation rules
- Edge cases (null, empty, max values)
- Error conditions
- Pure functions

❌ DON'T TEST:
- Third-party libraries
- Simple getters/setters
- Framework code
- Configuration
- Trivial code

Mocking Guidelines:

// ✅ GOOD: Mock external dependencies
const mockEmailService = {
  send: jest.fn().mockResolvedValue(true)
};

const mockDatabase = {
  query: jest.fn().mockResolvedValue([{ id: 1 }])
};

// ✅ GOOD: Use dependency injection
class UserService {
  constructor(private db: Database, private email: EmailService) {}

  async createUser(data) {
    const user = await this.db.save(data);
    await this.email.send(user.email, 'Welcome!');
    return user;
  }
}

// In test:
const service = new UserService(mockDb, mockEmail);

// ❌ BAD: Mocking internal implementation details
// This couples tests to implementation

Step 3: Write Integration Tests

API Integration Tests:

describe('POST /api/users', () => {
  let db: Database;

  beforeAll(async () => {
    db = await createTestDatabase();
  });

  afterAll(async () => {
    await db.close();
  });

  beforeEach(async () => {
    await db.query('DELETE FROM users');
  });

  it('creates a user and returns 201', async () => {
    const response = await request(app)
      .post('/api/users')
      .send({ email: 'test@example.com', name: 'Test' })
      .expect(201);

    expect(response.body).toMatchObject({
      id: expect.any(String),
      email: 'test@example.com'
    });

    // Verify in database
    const user = await db.users.findOne({ email: 'test@example.com' });
    expect(user).toBeDefined();
  });

  it('returns 400 for invalid data', async () => {
    const response = await request(app)
      .post('/api/users')
      .send({ email: 'invalid' })
      .expect(400);

    expect(response.body.error).toBe('Invalid email format');
  });

  it('returns 409 for duplicate email', async () => {
    await createUser({ email: 'test@example.com' });

    await request(app)
      .post('/api/users')
      .send({ email: 'test@example.com', name: 'Test' })
      .expect(409);
  });
});

Step 4: Write E2E Tests (Page Object Pattern)

Page Object:

// pages/LoginPage.ts
class LoginPage {
  constructor(private page: Page) {}

  async navigate() {
    await this.page.goto('/login');
  }

  async login(email: string, password: string) {
    await this.page.fill('[data-testid="email"]', email);
    await this.page.fill('[data-testid="password"]', password);
    await this.page.click('[data-testid="submit"]');
  }

  async getErrorMessage() {
    return this.page.textContent('[data-testid="error"]');
  }
}

// tests/login.spec.ts
describe('Login', () => {
  it('logs in successfully with valid credentials', async () => {
    const loginPage = new LoginPage(page);
    await loginPage.navigate();
    await loginPage.login('user@example.com', 'password');

    await expect(page).toHaveURL('/dashboard');
  });

  it('shows error for invalid credentials', async () => {
    const loginPage = new LoginPage(page);
    await loginPage.navigate();
    await loginPage.login('user@example.com', 'wrong');

    const error = await loginPage.getErrorMessage();
    expect(error).toBe('Invalid credentials');
  });
});

E2E Best Practices:

✅ DO:
- Use data-testid attributes
- Test user journeys, not features
- Run in realistic environment
- Handle async properly
- Clean up test data

❌ DON'T:
- Test every edge case with E2E
- Use brittle selectors (.class-name-xyz)
- Share state between tests
- Skip cleanup
- Run E2E on every commit (too slow)

Step 5: Test-Driven Development (TDD)

Red-Green-Refactor Cycle:

1. RED: Write a failing test
   └── Test describes desired behavior

2. GREEN: Write minimal code to pass
   └── Just enough to make test pass

3. REFACTOR: Clean up
   └── Improve code while tests pass

TDD Example:

// Step 1: RED - Write failing test
describe('Cart', () => {
  it('calculates total price with discount', () => {
    const cart = new Cart();
    cart.addItem({ price: 100, quantity: 2 });
    cart.applyDiscount(10); // 10%

    expect(cart.total).toBe(180); // (100 * 2) - 10%
  });
});

// Run test: FAILS (Cart doesn't exist yet)

// Step 2: GREEN - Minimal implementation
class Cart {
  items = [];
  discount = 0;

  addItem(item) {
    this.items.push(item);
  }

  applyDiscount(percent) {
    this.discount = percent;
  }

  get total() {
    const subtotal = this.items.reduce(
      (sum, i) => sum + i.price * i.quantity,
      0
    );
    return subtotal * (1 - this.discount / 100);
  }
}

// Run test: PASSES

// Step 3: REFACTOR - Clean up
class Cart {
  private items: CartItem[] = [];
  private discountPercent: number = 0;

  addItem(item: CartItem): void {
    this.items.push(item);
  }

  applyDiscount(percent: number): void {
    this.discountPercent = percent;
  }

  get total(): number {
    const subtotal = this.calculateSubtotal();
    return this.applyDiscountToSubtotal(subtotal);
  }

  private calculateSubtotal(): number {
    return this.items.reduce(
      (sum, item) => sum + item.price * item.quantity,
      0
    );
  }

  private applyDiscountToSubtotal(subtotal: number): number {
    return subtotal * (1 - this.discountPercent / 100);
  }
}

// Run test: STILL PASSES (refactoring didn't break anything)

Step 6: Test Coverage

Coverage Metrics:

LINE COVERAGE: % of lines executed
├── Easy to game
├── Doesn't ensure quality

BRANCH COVERAGE: % of decision branches
├── Better than line coverage
├── Catches missing else cases

MUTATION TESTING: % of mutations caught
├── Introduces bugs, checks if tests catch them
├── High quality metric
├── Slow to run

Coverage Guidelines:

## Coverage Targets

| Type | Target | Priority |
|------|--------|----------|
| Unit | 80% | Business logic |
| Integration | 60% | API endpoints |
| E2E | Key flows | User journeys |

### What Must Be Tested
- [ ] All public API functions
- [ ] All error handling paths
- [ ] Business rule edge cases
- [ ] Security-sensitive code

### What Can Be Skipped
- Configuration files
- Generated code
- Simple getters/setters
- Third-party wrappers

Test Organization

File Structure:

src/
├── users/
│   ├── user.service.ts
│   ├── user.service.test.ts       # Unit tests
│   ├── user.repository.ts
│   └── user.repository.test.ts
├── __tests__/
│   └── integration/
│       └── user.api.test.ts       # Integration tests
tests/
├── e2e/
│   ├── login.spec.ts              # E2E tests
│   └── checkout.spec.ts
├── fixtures/
│   └── users.json                 # Test data
└── setup.ts                       # Test configuration

Naming Conventions:

// Describe the unit being tested
describe('UserService', () => {
  // Describe the method
  describe('createUser', () => {
    // Describe the scenario
    describe('when email is valid', () => {
      // State what it does
      it('creates a new user', () => {});
      it('sends welcome email', () => {});
    });

    describe('when email already exists', () => {
      it('throws DuplicateEmailError', () => {});
    });
  });
});

Test Quality Checklist

## Test Review Checklist

### Structure
- [ ] Tests follow AAA pattern
- [ ] One assertion concept per test
- [ ] Descriptive test names
- [ ] Tests are independent
- [ ] No test interdependence

### Coverage
- [ ] Happy path tested
- [ ] Error cases tested
- [ ] Edge cases tested
- [ ] Boundary conditions tested

### Maintainability
- [ ] No flaky tests
- [ ] Setup/teardown is minimal
- [ ] Mocks are at boundaries
- [ ] Tests survive refactoring

### Performance
- [ ] Unit tests <100ms each
- [ ] Integration tests reasonable
- [ ] E2E tests focused
- [ ] Parallelization enabled

Common Testing Mistakes

Tools & Frameworks

JavaScript/TypeScript:

• Jest (unit + integration)
• Vitest (fast Jest alternative)
• Playwright (E2E)
• Cypress (E2E)
• Testing Library (React/Vue/etc)

Python:

• pytest (unit + integration)
• unittest (standard library)
• Selenium (E2E)

Ruby:

• RSpec (unit + integration)
• Capybara (E2E)

Go:

• testing package (standard library)
• testify (assertions)

Related Skills

• /code-review - Reviewing test quality
• /devops-cicd - Running tests in CI/CD
• /debugging - Using tests to find bugs

Last Updated: 2026-01-22