test-patterns

# 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](./references/unit-test-patterns.md) - Patterns for unit tests including mocking, fixtures, and assertions
- [Integration Test Patterns](./references/integration-test-patterns.md) - API and integration testing patterns
- [Test Data Factories](./references/test-data-factories.md) - Factory patterns for generating test data
- [Coverage Strategies](./references/coverage-strategies.md) - 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:

```python
# 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:

```python
def test_user_creation_sets_defaults():
    user = User.create(email="test@example.com")

    # 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:

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