Testing

Complete testing workflow covering all phases from test creation to validation, regression prevention, resilience testing, and E2E patterns.

Testing Workflow Phases

1. Test Creation (TDD Red Phase)

Write failing tests BEFORE implementation based on requirements.

Process:

1. Parse requirement - Read user story, identify functionality, extract acceptance criteria
2. Identify test cases - Happy path, error cases, edge cases, boundary conditions, invalid inputs
3. Write failing tests - Create test file, write test functions with descriptive names, assert expected behavior
4. Verify tests fail - Run tests, confirm they fail for the RIGHT reason (not syntax errors, but because functionality doesn't exist)
5. Document expected behavior - Test names describe what should happen, comments link to requirements

Test Types:

• Unit Tests - Individual functions/methods in isolation
• Integration Tests - Component interactions
• Contract Tests - API boundaries
• Acceptance Tests - Business requirements

Best Practices:

• Test one thing per test
• Use descriptive names (e.g., test_user_registration_creates_account)
• Arrange-Act-Assert structure
• No implementation - tests only
• Verify failure before implementing
• Link to requirements in comments

2. Acceptance Validation

Validates that implementation meets business requirements and acceptance criteria.

Process:

1. Parse original requirement - Extract business need and acceptance criteria
2. Map criteria to tests - Link each criterion to specific test(s)
3. Verify all criteria met - Run tests and confirm each passes
4. Generate acceptance report - Create report showing criteria status

Acceptance Criteria Formats:

• User Story Format: "As a [role] I want [feature] So that [benefit]"
• Given-When-Then Format: "Given [context] When [action] Then [outcome]"

Validation Checks:

• All criteria have tests
• All tests pass
• Tests match criteria (verify test actually tests the criterion)
• Edge cases covered (negative, boundary, performance)

Output Format:

• Requirement summary
• Criteria status table (✅/❌/⚠️)
• Overall verdict (ACCEPTED/REJECTED/PARTIAL)
• Test coverage percentage
• Outstanding issues
• Recommendations

3. Regression Prevention

Ensures changes don't break existing functionality by verifying all tests pass and coverage doesn't decrease.

Checks Performed:

1. All existing tests pass - Every test must pass before changes accepted
2. Coverage doesn't decrease - Code coverage should not drop below current level
3. No new warnings - New code should not introduce warnings
4. Performance benchmarks maintained - Critical operations should not become slower
5. API contracts unchanged - Public APIs should remain compatible

Blocking Conditions: Changes are BLOCKED if:

• ❌ Any test failure
• ❌ Coverage drop > 2%
• ❌ New deprecation warnings
• ❌ Performance regression > 10%
• ❌ Breaking API changes (unintentional)

Workflow:

• Before Changes: Run all tests, measure coverage baseline, run performance benchmarks
• After Changes: Run all tests, compare results with baseline, check coverage hasn't dropped, verify performance maintained

Best Practices:

• Run regression checks before every commit
• Maintain high test coverage (>80%)
• Fix flaky tests immediately
• Monitor performance trends
• Keep tests fast
• Test in isolation
• Version APIs for graceful deprecation

4. Resilience Testing

Tests system resilience - error handling, edge cases, load, recovery.

Resilience Categories:

1. Error Handling - Invalid inputs, type mismatches, missing fields
2. Network Resilience - Timeouts, transient failures, circuit breakers
3. Database Resilience - Connection failures, transaction rollbacks, deadlocks
4. Load Resilience - Concurrent requests, rate limiting, queue overflow
5. Recovery & Idempotency - State recovery, graceful degradation, idempotent operations
6. Edge Cases & Boundaries - Empty input, large input, boundary values, unicode

Test Patterns:

• Retry Pattern - Exponential backoff on failures
• Circuit Breaker - Fail fast when service is down
• Bulkhead - Isolate failures to prevent cascading

Best Practices:

• Test failure scenarios, not just happy path
• Use realistic failures (network timeouts, database errors)
• Test recovery mechanisms
• Test under load (concurrent requests, high volume)
• Test boundaries (min/max values, empty inputs)
• Test idempotency
• Verify error messages are clear and actionable

5. E2E Testing Patterns

End-to-end testing patterns and examples for browser, API, and CLI workflows.

Test Types:

• Browser-Based E2E (Playwright) - Full UI workflows testing complete user journeys
• API-Based E2E - Complete API workflows from authentication to data operations
• CLI-Based E2E - Command-line workflows from initialization to deployment

Test Patterns:

• Happy Path Test - Test successful completion of user workflow
• Error Recovery Test - Test user recovery from error scenarios
• Multi-User Scenario - Test collaborative workflows with multiple users

Best Practices:

• Test real user flows, not just API endpoints
• Use realistic test data
• Test error scenarios, not just happy path
• Keep tests independent
• Clean up after tests
• Run against staging environment
• Monitor test duration
• Use page objects for browser tests
• Verify visual elements with screenshots
• Test accessibility

Complete TDD Workflow

1. Red: Create failing tests (Test Creation phase)
2. Green: Implement minimum code to pass tests
3. Refactor: Improve code while keeping tests green
4. Resilience: Add error handling and edge case tests (Resilience Testing phase)
5. Validate: Verify acceptance criteria met (Acceptance Validation phase)
6. Guard: Ensure no regressions (Regression Prevention phase)
7. E2E: Validate complete user flows (E2E Testing Patterns phase)

See docs/TDD-METHODOLOGY.md for detailed TDD methodology guide including Red-Green-Refactor cycle, todo creation templates, best practices, and common mistakes.

See examples.md for complete code examples and patterns.