Test generation process

--- model: claude-sonnet-4-0 --- Write comprehensive failing tests following TDD red phase principles: [Extended thinking: This tool uses the test-automator agent to generate comprehensive failing tests that properly define expected behavior. It ensures tests fail for the right reasons and establishes a solid foundation for implementation.] ## Test Generation Process Use Task tool with subagenttype="test-automator" to generate failing tests. Prompt: "Generate comprehensive FAILING tests for: $ARGUMENTS. Follow TDD red phase principles: 1. **Test Structure Setup** - Choose appropriate testing framework for the language/stack - Set up test fixtures and necessary imports - Configure test runners and assertion libraries - Establish test naming conventions (shouldXwhenY format) 2. Behavior Definition - Define clear expected behaviors from requirements - Cover happy path scenarios thoroughly - Include edge cases and boundary conditions - Add error handling and exception scenarios - Consider null/undefined/empty input cases 3. Test Implementation - Write descriptive test names that document intent - Keep tests focused on single behaviors (one assertion per test when possible) - Use Arrange-Act-Assert (AAA) pattern consistently - Implement test data builders for complex objects - Avoid test interdependencies - each test must be isolated 4. Failure Verification - Ensure tests actually fail when run - Verify failure messages are meaningful and diagnostic - Confirm tests fail for the RIGHT reasons (not syntax/import errors) - Check that error messages guide implementation - Validate test isolation - no cascading failures 5. Test Categories - Unit Tests: Isolated component behavior - Integration Tests: Component interaction scenarios - Contract Tests: API and interface contracts - Property Tests: Invariants and mathematical properties - Acceptance Tests: User story validation 6. Framework-Specific Patterns - JavaScript/TypeScript: Jest, Mocha, Vitest patterns - Python: pytest fixtures and parameterization - Java: JUnit5 annotations and assertions - C#: NUnit/xUnit attributes and theory data - Go: Table-driven tests and subtests - Ruby: RSpec expectations and contexts 7. Test Quality Checklist ✓ Tests are readable and self-documenting ✓ Failure messages clearly indicate what went wrong ✓ Tests follow DRY principle with appropriate abstractions ✓ Coverage includes positive, negative, and edge cases ✓ Tests can serve as living documentation ✓ No implementation details leaked into tests ✓ Tests use meaningful test data, not 'foo' and 'bar' 8. Common Anti-Patterns to Avoid - Writing tests that pass immediately - Testing implementation instead of behavior - Overly complex test setup - Brittle tests tied to specific implementations - Tests with multiple responsibilities - Ignored or commented-out tests - Tests without clear assertions Output should include: - Complete test file(s) with all necessary imports - Clear documentation of what each test validates - Verification commands to run tests and see failures - Metrics: number of tests, coverage areas, test categories - Next steps for moving to green phase" ## Validation Steps After test generation: 1. Run tests to confirm they fail 2. Verify failure messages are helpful 3. Check test independence and isolation 4. Ensure comprehensive coverage 5. Document any assumptions made ## Recovery Process If tests don't fail properly: - Debug import/syntax issues first - Ensure test framework is properly configured - Verify assertions are actually checking behavior - Add more specific assertions if needed - Consider missing test categories ## Integration Points - Links to tdd-green.md for implementation phase - Coordinates with tdd-refactor.md for improvement phase - Integrates with CI/CD for automated verification - Connects to test coverage reporting tools ## Best Practices - Start with the simplest failing test - One behavior change at a time - Tests should tell a story of the feature - Prefer many small tests over few large ones - Use test naming as documentation - Keep test code as clean as production code Test requirements: $ARGUMENTS