Write comprehensive failing tests following TDD red phase principles.
[Extended thinking: Generates failing tests that properly define expected behavior using test-automator agent.]
Use this skill when
- Starting the TDD red phase for new behavior
- You need failing tests that capture expected behavior
- You want edge case coverage before implementation
Do not use this skill when
- You are in the green or refactor phase
- You only need performance benchmarks
- Tests must run against production systems
Instructions
- Identify behaviors, constraints, and edge cases.
- Generate failing tests that define expected outcomes.
- Ensure failures are due to missing behavior, not setup errors.
- Document how to run tests and verify failures.
Safety
- Keep test data isolated and avoid production environments.
- Avoid flaky external dependencies in the red phase.
Role
Generate failing tests using Task tool with subagent_type="unit-testing::test-automator".
Prompt Template
"Generate comprehensive FAILING tests for: $ARGUMENTS
Core Requirements
Test Structure
- Framework-appropriate setup (Jest/pytest/JUnit/Go/RSpec)
- Arrange-Act-Assert pattern
- should_X_when_Y naming convention
- Isolated fixtures with no interdependencies
Behavior Coverage
- Happy path scenarios
- Edge cases (empty, null, boundary values)
- Error handling and exceptions
- Concurrent access (if applicable)
Failure Verification
- Tests MUST fail when run
- Failures for RIGHT reasons (not syntax/import errors)
- Meaningful diagnostic error messages
- No cascading failures
Test Categories
- Unit: Isolated component behavior
- Integration: Component interaction
- Contract: API/interface contracts
- Property: Mathematical invariants
Framework Patterns
JavaScript/TypeScript (Jest/Vitest)
- Mock dependencies with
vi.fn() or jest.fn()
- Use
@testing-library for React components
- Property tests with
fast-check
Python (pytest)
- Fixtures with appropriate scopes
- Parametrize for multiple test cases
- Hypothesis for property-based tests
Go
- Table-driven tests with subtests
t.Parallel() for parallel execution
- Use
testify/assert for cleaner assertions
Ruby (RSpec)
let for lazy loading, let! for eager
- Contexts for different scenarios
- Shared examples for common behavior
Quality Checklist
- Readable test names documenting intent
- One behavior per test
- No implementation leakage
- Meaningful test data (not 'foo'/'bar')
- Tests serve as living documentation
Anti-Patterns to Avoid
- Tests passing immediately
- Testing implementation vs behavior
- Complex setup code
- Multiple responsibilities per test
- Brittle tests tied to specifics
Edge Case Categories
- Null/Empty: undefined, null, empty string/array/object
- Boundaries: min/max values, single element, capacity limits
- Special Cases: Unicode, whitespace, special characters
- State: Invalid transitions, concurrent modifications
- Errors: Network failures, timeouts, permissions
Output Requirements
- Complete test files with imports
- Documentation of test purpose
- Commands to run and verify failures
- Metrics: test count, coverage areas
- Next steps for green phase"
Validation
After generation:
- Run tests - confirm they fail
- Verify helpful failure messages
- Check test independence
- Ensure comprehensive coverage
Example (Minimal)
// auth.service.test.ts
describe('AuthService', () => {
let authService: AuthService;
let mockUserRepo: jest.Mocked<UserRepository>;
beforeEach(() => {
mockUserRepo = { findByEmail: jest.fn() } as any;
authService = new AuthService(mockUserRepo);
});
it('should_return_token_when_valid_credentials', async () => {
const user = { id: '1', email: 'test@example.com', passwordHash: 'hashed' };
mockUserRepo.findByEmail.mockResolvedValue(user);
const result = await authService.authenticate('test@example.com', 'pass');
expect(result.success).toBe(true);
expect(result.token).toBeDefined();
});
it('should_fail_when_user_not_found', async () => {
mockUserRepo.findByEmail.mockResolvedValue(null);
const result = await authService.authenticate('none@example.com', 'pass');
expect(result.success).toBe(false);
expect(result.error).toBe('INVALID_CREDENTIALS');
});
});
Test requirements: $ARGUMENTS
1---2name: tdd-workflows-tdd-red3description: Write comprehensive failing tests following TDD red phase principles.4---5Write comprehensive failing tests following TDD red phase principles.67[Extended thinking: Generates failing tests that properly define expected behavior using test-automator agent.]89## Use this skill when1011- Starting the TDD red phase for new behavior12- You need failing tests that capture expected behavior13- You want edge case coverage before implementation1415## Do not use this skill when1617- You are in the green or refactor phase18- You only need performance benchmarks19- Tests must run against production systems2021## Instructions22231. Identify behaviors, constraints, and edge cases.242. Generate failing tests that define expected outcomes.253. Ensure failures are due to missing behavior, not setup errors.264. Document how to run tests and verify failures.2728## Safety2930- Keep test data isolated and avoid production environments.31- Avoid flaky external dependencies in the red phase.3233## Role3435Generate failing tests using Task tool with subagent_type="unit-testing::test-automator".3637## Prompt Template3839"Generate comprehensive FAILING tests for: $ARGUMENTS4041## Core Requirements42431. **Test Structure**44 - Framework-appropriate setup (Jest/pytest/JUnit/Go/RSpec)45 - Arrange-Act-Assert pattern46 - should_X_when_Y naming convention47 - Isolated fixtures with no interdependencies48492. **Behavior Coverage**50 - Happy path scenarios51 - Edge cases (empty, null, boundary values)52 - Error handling and exceptions53 - Concurrent access (if applicable)54553. **Failure Verification**56 - Tests MUST fail when run57 - Failures for RIGHT reasons (not syntax/import errors)58 - Meaningful diagnostic error messages59 - No cascading failures60614. **Test Categories**62 - Unit: Isolated component behavior63 - Integration: Component interaction64 - Contract: API/interface contracts65 - Property: Mathematical invariants6667## Framework Patterns6869**JavaScript/TypeScript (Jest/Vitest)**70- Mock dependencies with `vi.fn()` or `jest.fn()`71- Use `@testing-library` for React components72- Property tests with `fast-check`7374**Python (pytest)**75- Fixtures with appropriate scopes76- Parametrize for multiple test cases77- Hypothesis for property-based tests7879**Go**80- Table-driven tests with subtests81- `t.Parallel()` for parallel execution82- Use `testify/assert` for cleaner assertions8384**Ruby (RSpec)**85- `let` for lazy loading, `let!` for eager86- Contexts for different scenarios87- Shared examples for common behavior8889## Quality Checklist9091- Readable test names documenting intent92- One behavior per test93- No implementation leakage94- Meaningful test data (not 'foo'/'bar')95- Tests serve as living documentation9697## Anti-Patterns to Avoid9899- Tests passing immediately100- Testing implementation vs behavior101- Complex setup code102- Multiple responsibilities per test103- Brittle tests tied to specifics104105## Edge Case Categories106107- **Null/Empty**: undefined, null, empty string/array/object108- **Boundaries**: min/max values, single element, capacity limits109- **Special Cases**: Unicode, whitespace, special characters110- **State**: Invalid transitions, concurrent modifications111- **Errors**: Network failures, timeouts, permissions112113## Output Requirements114115- Complete test files with imports116- Documentation of test purpose117- Commands to run and verify failures118- Metrics: test count, coverage areas119- Next steps for green phase"120121## Validation122123After generation:1241. Run tests - confirm they fail1252. Verify helpful failure messages1263. Check test independence1274. Ensure comprehensive coverage128129## Example (Minimal)130131```typescript132// auth.service.test.ts133describe('AuthService', () => {134 let authService: AuthService;135 let mockUserRepo: jest.Mocked<UserRepository>;136137 beforeEach(() => {138 mockUserRepo = { findByEmail: jest.fn() } as any;139 authService = new AuthService(mockUserRepo);140 });141142 it('should_return_token_when_valid_credentials', async () => {143 const user = { id: '1', email: 'test@example.com', passwordHash: 'hashed' };144 mockUserRepo.findByEmail.mockResolvedValue(user);145146 const result = await authService.authenticate('test@example.com', 'pass');147148 expect(result.success).toBe(true);149 expect(result.token).toBeDefined();150 });151152 it('should_fail_when_user_not_found', async () => {153 mockUserRepo.findByEmail.mockResolvedValue(null);154155 const result = await authService.authenticate('none@example.com', 'pass');156157 expect(result.success).toBe(false);158 expect(result.error).toBe('INVALID_CREDENTIALS');159 });160});161```162163Test requirements: $ARGUMENTS