test-patterns

name	test-patterns
description	Patterns for generating and organizing tests — unit, integration, data factories, coverage strategies — across multiple languages and frameworks. Trigger on test-writing or coverage-improvement requests.

Test Patterns Skill

Generate and organize tests following project conventions and industry best practices.

When to Use

• Generating unit tests for new or existing code
• Creating integration/API tests
• Setting up test data factories
• Analyzing and improving test coverage
• Establishing testing conventions in a project

Reference Documents

• Unit Test Patterns - Patterns for unit tests including mocking, fixtures, and assertions
• Integration Test Patterns - API and integration testing patterns
• Test Data Factories - Factory patterns for generating test data
• Coverage Strategies - Approaches to meaningful test coverage

Core Principles

1. Test Behavior, Not Implementation

WRONG: Testing internal method calls
RIGHT: Testing observable behavior and outputs

Tests should verify what code does, not how it does it. This makes tests resilient to refactoring.

2. Arrange-Act-Assert (AAA) Pattern

Every test should have three distinct sections:

# Arrange - Set up test data and conditions
user = create_user(name="Alice")
order = create_order(user=user, items=[item1, item2])

# Act - Execute the behavior being tested
result = order.calculate_total()

# Assert - Verify the expected outcome
assert result == 150.00

3. One Assertion Per Test (Logical)

Each test should verify one logical concept, though it may have multiple assertions for that concept:

def test_user_creation_sets_defaults():
    user = User.create(email="[e-mail]")

    # Multiple assertions for one concept: default values
    assert user.status == "pending"
    assert user.role == "member"
    assert user.created_at is not None

4. Descriptive Test Names

Test names should describe the scenario and expected outcome:

# WRONG
def test_order():
def test_calculate():

# RIGHT
def test_order_with_discount_applies_percentage_reduction():
def test_calculate_total_includes_tax_for_taxable_items():

5. Test Independence

Tests must not depend on each other or on execution order:

• Each test sets up its own data
• Each test cleans up after itself (or uses transactions)
• No shared mutable state between tests

Workflow: Generating Tests

Step 1: Analyze the Code Under Test

1. Read the file/function to be tested
2. Identify public interfaces and behaviors
3. List edge cases and error conditions
4. Note dependencies that need mocking

Step 2: Determine Test Type

Code Type	Test Type	Focus
Pure function	Unit test	Input/output
Class with dependencies	Unit test with mocks	Behavior
API endpoint	Integration test	Request/response
Database operation	Integration test	Data persistence
External service call	Unit test with mocks	Contract

Step 3: Create Test Structure

tests/
├── unit/
│   └── [module]/
│       └── test_[file].py
├── integration/
│   └── test_[feature].py
└── fixtures/
    └── [shared fixtures]

Step 4: Write Tests

Follow the patterns in reference documents for specific test types.

Step 5: Verify Coverage

Run coverage analysis and add tests for uncovered critical paths.

Language-Specific Patterns

Python (pytest)

import pytest
from unittest.mock import Mock, patch

class TestOrderCalculation:
    @pytest.fixture
    def order(self):
        return Order(items=[Item(price=100), Item(price=50)])

    def test_calculates_subtotal(self, order):
        assert order.subtotal == 150

    @pytest.mark.parametrize("discount,expected", [
        (0, 150),
        (10, 135),
        (50, 75),
    ])
    def test_applies_discount(self, order, discount, expected):
        order.apply_discount(discount)
        assert order.total == expected

TypeScript (Jest/Vitest)

import { describe, it, expect, vi } from 'vitest';

describe('OrderService', () => {
  it('calculates total with tax', () => {
    const order = new Order([
      { price: 100 },
      { price: 50 }
    ]);

    expect(order.totalWithTax(0.1)).toBe(165);
  });

  it('sends confirmation email on completion', async () => {
    const emailService = { send: vi.fn() };
    const order = new Order([], { emailService });

    await order.complete();

    expect(emailService.send).toHaveBeenCalledWith(
      expect.objectContaining({ type: 'confirmation' })
    );
  });
});

Ruby (RSpec)

RSpec.describe Order do
  subject(:order) { described_class.new(items: items) }
  let(:items) { [Item.new(price: 100), Item.new(price: 50)] }

  describe '#total' do
    it 'sums item prices' do
      expect(order.total).to eq(150)
    end

    context 'with discount applied' do
      before { order.apply_discount(10) }

      it 'reduces total by percentage' do
        expect(order.total).to eq(135)
      end
    end
  end
end

Quick Reference

Pattern	When to Use
Factory	Creating test objects with defaults
Builder	Creating complex test objects step-by-step
Mock	Replacing dependencies
Stub	Providing canned responses
Spy	Verifying method calls
Fake	Lightweight implementation for testing
Fixture	Shared test data setup
Parametrize	Testing multiple inputs