test-writer

Test Writer

Writes tests that actually catch bugs — not tests that just run green.

When to Use

• "Write tests for this function"
• "Add tests before I refactor this"
• "What should I test here?"
• "My coverage is low — where do I start?"

What Makes a Test Valuable

A test is valuable if it would fail when the code is wrong and pass when the code is correct. A test that always passes regardless of the implementation has negative value — it creates false confidence.

Before writing any test, ask: "If I deleted the function body and replaced it with return null, would this test fail?" If no, the test is measuring nothing.

Test Categories (write in this order)

1. Happy Path

The expected behavior with valid inputs. Should be the first test, simplest to write.

2. Edge Cases

The boundaries where behavior changes:

• Empty inputs (empty string, empty array, null, undefined)
• Zero and negative numbers
• Single-element collections
• Maximum/minimum values
• Boundary conditions (n=0, n=1, n=N, n=N+1)

3. Error Cases

What happens when things go wrong:

• Invalid input types
• Missing required fields
• Values out of range
• External service failures (mocked)
• Concurrent access

4. Integration Points

Where this code meets other systems:

• Database reads/writes produce expected results
• External API calls are made with correct parameters
• Events are emitted in the right order
• State is cleaned up after use

Test Structure

Every test follows Arrange → Act → Assert:

def test_descriptive_name_of_what_is_being_verified():
    # Arrange — set up the exact state needed
    user = User(id=1, email="[email protected]", role="admin")
    
    # Act — run exactly one thing
    result = can_delete_post(user, post_id=42)
    
    # Assert — verify the specific outcome
    assert result is True

One assertion per test is a guideline, not a rule. Multiple assertions are fine when they verify a single behavior. Multiple behaviors in one test = split into multiple tests.