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: Generate failing tests for the TDD red phase to define expected behavior and edge cases.4---5
6Write comprehensive failing tests following TDD red phase principles.
7
8[Extended thinking: Generates failing tests that properly define expected behavior using test-automator agent.]
9
10## Use this skill when
11
12- Starting the TDD red phase for new behavior
13- You need failing tests that capture expected behavior
14- You want edge case coverage before implementation
15
16## Do not use this skill when
17
18- You are in the green or refactor phase
19- You only need performance benchmarks
20- Tests must run against production systems
21
22## Instructions
23
241. Identify behaviors, constraints, and edge cases.
252. Generate failing tests that define expected outcomes.
263. Ensure failures are due to missing behavior, not setup errors.
274. Document how to run tests and verify failures.
28
29## Safety
30
31- Keep test data isolated and avoid production environments.
32- Avoid flaky external dependencies in the red phase.
33
34## Role
35
36Generate failing tests using Task tool with subagent_type="unit-testing::test-automator".
37
38## Prompt Template
39
40"Generate comprehensive FAILING tests for: $ARGUMENTS
41
42## Core Requirements
43
441. **Test Structure**
45 - Framework-appropriate setup (Jest/pytest/JUnit/Go/RSpec)
46 - Arrange-Act-Assert pattern
47 - should_X_when_Y naming convention
48 - Isolated fixtures with no interdependencies
49
502. **Behavior Coverage**
51 - Happy path scenarios
52 - Edge cases (empty, null, boundary values)
53 - Error handling and exceptions
54 - Concurrent access (if applicable)
55
563. **Failure Verification**
57 - Tests MUST fail when run
58 - Failures for RIGHT reasons (not syntax/import errors)
59 - Meaningful diagnostic error messages
60 - No cascading failures
61
624. **Test Categories**
63 - Unit: Isolated component behavior
64 - Integration: Component interaction
65 - Contract: API/interface contracts
66 - Property: Mathematical invariants
67
68## Framework Patterns
69
70**JavaScript/TypeScript (Jest/Vitest)**
71- Mock dependencies with `vi.fn()` or `jest.fn()`
72- Use `@testing-library` for React components
73- Property tests with `fast-check`
74
75**Python (pytest)**
76- Fixtures with appropriate scopes
77- Parametrize for multiple test cases
78- Hypothesis for property-based tests
79
80**Go**
81- Table-driven tests with subtests
82- `t.Parallel()` for parallel execution
83- Use `testify/assert` for cleaner assertions
84
85**Ruby (RSpec)**
86- `let` for lazy loading, `let!` for eager
87- Contexts for different scenarios
88- Shared examples for common behavior
89
90## Quality Checklist
91
92- Readable test names documenting intent
93- One behavior per test
94- No implementation leakage
95- Meaningful test data (not 'foo'/'bar')
96- Tests serve as living documentation
97
98## Anti-Patterns to Avoid
99
100- Tests passing immediately
101- Testing implementation vs behavior
102- Complex setup code
103- Multiple responsibilities per test
104- Brittle tests tied to specifics
105
106## Edge Case Categories
107
108- **Null/Empty**: undefined, null, empty string/array/object
109- **Boundaries**: min/max values, single element, capacity limits
110- **Special Cases**: Unicode, whitespace, special characters
111- **State**: Invalid transitions, concurrent modifications
112- **Errors**: Network failures, timeouts, permissions
113
114## Output Requirements
115
116- Complete test files with imports
117- Documentation of test purpose
118- Commands to run and verify failures
119- Metrics: test count, coverage areas
120- Next steps for green phase"
121
122## Validation
123
124After generation:
1251. Run tests - confirm they fail
1262. Verify helpful failure messages
1273. Check test independence
1284. Ensure comprehensive coverage
129
130## Example (Minimal)
131
132```typescript
133// auth.service.test.ts
134describe('AuthService', () => {
135 let authService: AuthService;
136 let mockUserRepo: jest.Mocked<UserRepository>;
137
138 beforeEach(() => {
139 mockUserRepo = { findByEmail: jest.fn() } as any;
140 authService = new AuthService(mockUserRepo);
141 });
142
143 it('should_return_token_when_valid_credentials', async () => {
144 const user = { id: '1', email: 'test@example.com', passwordHash: 'hashed' };
145 mockUserRepo.findByEmail.mockResolvedValue(user);
146
147 const result = await authService.authenticate('test@example.com', 'pass');
148
149 expect(result.success).toBe(true);
150 expect(result.token).toBeDefined();
151 });
152
153 it('should_fail_when_user_not_found', async () => {
154 mockUserRepo.findByEmail.mockResolvedValue(null);
155
156 const result = await authService.authenticate('none@example.com', 'pass');
157
158 expect(result.success).toBe(false);
159 expect(result.error).toBe('INVALID_CREDENTIALS');
160 });
161});
162```
163
164Test requirements: $ARGUMENTS