Test-First Thinking

Overview

When to Use This Skill

Explicit Triggers

• "Think about tests first"
• "Design for testability"
• "What tests do I need?"
• "Use test-first approach"
• "TDD thinking"
• "How should I test this?"

Implicit Triggers

• Before creating a new class or method
• Before refactoring existing code
• When starting a new feature implementation
• When reviewing code that lacks tests
• When design feels overly complex

Debugging Triggers

• Tests are difficult to write for existing code
• Code requires extensive mocking to test
• Implementation has grown too complex
• Edge cases keep surfacing after deployment

What This Skill Does

1. Feature enumeration - List all expected behaviors before coding
2. Simplicity check - Consider maintainability and complexity
3. Test identification - Know what tests validate each behavior
4. Interface design - Create signatures that make testing easy
5. Edge case awareness - Think through error conditions upfront

The Test-First Checklist

1. Enumerate Features and Behaviors

• What should this class/method do?
• What are the expected inputs and outputs?
• What transformations or side effects occur?

# Before implementing UserRegistration class, list features:
# 1. Validate email format
# 2. Check if email already exists
# 3. Hash password securely
# 4. Store user in database
# 5. Send confirmation email
# 6. Return success/failure result

2. Consider Edge Cases and Error Conditions

• What can go wrong?
• How should errors be handled?
• What are the boundary conditions?

# Edge cases for UserRegistration:
# - Invalid email format
# - Duplicate email
# - Weak password
# - Database connection failure
# - Email service unavailable
# - Null/empty inputs

3. Identify Required Tests

• What test cases validate each feature?
• How do I verify error handling?
• What mocks/fixtures are needed?

# Tests needed for UserRegistration:
# - test_valid_registration_succeeds()
# - test_invalid_email_raises_validation_error()
# - test_duplicate_email_returns_failure()
# - test_weak_password_raises_validation_error()
# - test_database_failure_returns_failure()
# - test_email_service_failure_logs_warning()
# - test_null_inputs_raise_value_error()

4. Design for Testability

• Does this interface make testing easy?
• Can I test without complex mocking?
• Are dependencies explicit and injectable?
• Is the function pure (no hidden side effects)?

def register_user(
    email: str,
    password: str,
    user_repo: UserRepository,
    email_service: EmailService
) -> Result[User, RegistrationError]:
    """Register new user with explicit dependencies."""
    # Dependencies are injected - easy to mock
    # Returns Result type - easy to test both paths
    # Pure function - predictable behavior

def register_user(email: str, password: str) -> None:
    """Register new user."""
    # Hidden dependency on global database connection
    # Hidden dependency on email service
    # No return value - can't verify success
    # Side effects make testing difficult

5. Look at Existing Tests First

1. Read the test file BEFORE modifying implementation
2. Existing tests show what features the code should have
3. If tests are missing, write them first
4. If tests are hard to understand, the code is likely too complex

# Before editing src/auth/registration.py:
# 1. Read tests/unit/auth/test_registration.py
# 2. Understand what behaviors are tested
# 3. Identify what's NOT tested (gaps)
# 4. Add tests for new behavior
# 5. THEN modify implementation

6. Implement

• Write the implementation
• Run tests continuously as you code
• Refactor based on test feedback
• Add tests if new edge cases emerge

Quick Reference: Red Flags

• "I'll write tests later" - Write tests now or redesign
• "This needs extensive mocking" - Dependencies may be too coupled
• "I can't describe what tests I'd write" - Design is too complex
• "Tests would be too complicated" - Implementation is too complicated
• "This is hard to test" - This is hard to maintain
• "I need to mock everything" - Too many dependencies
• "Tests keep breaking" - Implementation is too fragile

Benefits

Integration with Quality Gates

• quality-run-quality-gates - Ensures tests exist before marking complete
• quality-capture-baseline - Requires test coverage metrics
• quality-detect-regressions - Verifies tests pass consistently
• test-debug-failures - Makes test failures easier to diagnose

Expected Outcomes

Success

Before implementing PaymentProcessor class:

Features enumerated:
✅ Process credit card payment
✅ Validate payment amount
✅ Handle payment gateway response
✅ Store transaction record
✅ Send receipt email

Edge cases identified:
✅ Invalid card number
✅ Insufficient funds
✅ Gateway timeout
✅ Network failure
✅ Duplicate transaction

Tests identified:
✅ test_valid_payment_succeeds()
✅ test_invalid_card_raises_error()
✅ test_insufficient_funds_returns_failure()
✅ test_gateway_timeout_retries()
✅ test_duplicate_transaction_prevented()

Interface designed:
✅ Dependencies injected (gateway, transaction_repo)
✅ Returns Result type for error handling
✅ Pure function - no hidden state
✅ Easy to mock gateway for testing

Ready to implement with confidence!

Failure (Redesign Needed)

Before implementing ReportGenerator class:

Attempted to list features:
❌ "Generate reports" - too vague
❌ "Process data" - what data? how?
❌ Multiple responsibilities identified
❌ Can't describe specific behaviors

Attempted to identify tests:
❌ "Test that it works" - not specific enough
❌ Would need to mock 15+ dependencies
❌ No clear success/failure paths
❌ Can't isolate behaviors for testing

Red flags:
❌ Design too complex
❌ Unclear responsibilities
❌ Too many dependencies
❌ Not testable in current form

Action: Break into smaller, focused classes:
- ReportDataFetcher (single responsibility)
- ReportFormatter (single responsibility)
- ReportExporter (single responsibility)

Retry test-first thinking for each class individually.

Notes

1. This is NOT strict TDD - You don't have to write tests first, but you must THINK about tests first
2. Mental model matters - The discipline of considering testability improves design
3. Start simple - If you can't explain it simply, you don't understand it well enough
4. Tests reveal design flaws - Hard to test = hard to maintain
5. Iterate - If tests are difficult, redesign the interface
6. Use existing tests as documentation - They show what the code should do
7. Testability IS maintainability - They're the same thing

Supporting Files