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="general-purpose".
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."4risk: unknown5source: community6---78Write comprehensive failing tests following TDD red phase principles.910[Extended thinking: Generates failing tests that properly define expected behavior using test-automator agent.]1112## Use this skill when1314- Starting the TDD red phase for new behavior15- You need failing tests that capture expected behavior16- You want edge case coverage before implementation1718## Do not use this skill when1920- You are in the green or refactor phase21- You only need performance benchmarks22- Tests must run against production systems2324## Instructions25261. Identify behaviors, constraints, and edge cases.272. Generate failing tests that define expected outcomes.283. Ensure failures are due to missing behavior, not setup errors.294. Document how to run tests and verify failures.3031## Safety3233- Keep test data isolated and avoid production environments.34- Avoid flaky external dependencies in the red phase.3536## Role3738Generate failing tests using Task tool with subagent_type="general-purpose".3940## Prompt Template4142"Generate comprehensive FAILING tests for: $ARGUMENTS4344## Core Requirements45461. **Test Structure**47 - Framework-appropriate setup (Jest/pytest/JUnit/Go/RSpec)48 - Arrange-Act-Assert pattern49 - should_X_when_Y naming convention50 - Isolated fixtures with no interdependencies51522. **Behavior Coverage**53 - Happy path scenarios54 - Edge cases (empty, null, boundary values)55 - Error handling and exceptions56 - Concurrent access (if applicable)57583. **Failure Verification**59 - Tests MUST fail when run60 - Failures for RIGHT reasons (not syntax/import errors)61 - Meaningful diagnostic error messages62 - No cascading failures63644. **Test Categories**65 - Unit: Isolated component behavior66 - Integration: Component interaction67 - Contract: API/interface contracts68 - Property: Mathematical invariants6970## Framework Patterns7172**JavaScript/TypeScript (Jest/Vitest)**73- Mock dependencies with `vi.fn()` or `jest.fn()`74- Use `@testing-library` for React components75- Property tests with `fast-check`7677**Python (pytest)**78- Fixtures with appropriate scopes79- Parametrize for multiple test cases80- Hypothesis for property-based tests8182**Go**83- Table-driven tests with subtests84- `t.Parallel()` for parallel execution85- Use `testify/assert` for cleaner assertions8687**Ruby (RSpec)**88- `let` for lazy loading, `let!` for eager89- Contexts for different scenarios90- Shared examples for common behavior9192## Quality Checklist9394- Readable test names documenting intent95- One behavior per test96- No implementation leakage97- Meaningful test data (not 'foo'/'bar')98- Tests serve as living documentation99100## Anti-Patterns to Avoid101102- Tests passing immediately103- Testing implementation vs behavior104- Complex setup code105- Multiple responsibilities per test106- Brittle tests tied to specifics107108## Edge Case Categories109110- **Null/Empty**: undefined, null, empty string/array/object111- **Boundaries**: min/max values, single element, capacity limits112- **Special Cases**: Unicode, whitespace, special characters113- **State**: Invalid transitions, concurrent modifications114- **Errors**: Network failures, timeouts, permissions115116## Output Requirements117118- Complete test files with imports119- Documentation of test purpose120- Commands to run and verify failures121- Metrics: test count, coverage areas122- Next steps for green phase"123124## Validation125126After generation:1271. Run tests - confirm they fail1282. Verify helpful failure messages1293. Check test independence1304. Ensure comprehensive coverage131132## Example (Minimal)133134```typescript135// auth.service.test.ts136describe('AuthService', () => {137 let authService: AuthService;138 let mockUserRepo: jest.Mocked<UserRepository>;139140 beforeEach(() => {141 mockUserRepo = { findByEmail: jest.fn() } as any;142 authService = new AuthService(mockUserRepo);143 });144145 it('should_return_token_when_valid_credentials', async () => {146 const user = { id: '1', email: 'test@example.com', passwordHash: 'hashed' };147 mockUserRepo.findByEmail.mockResolvedValue(user);148149 const result = await authService.authenticate('test@example.com', 'pass');150151 expect(result.success).toBe(true);152 expect(result.token).toBeDefined();153 });154155 it('should_fail_when_user_not_found', async () => {156 mockUserRepo.findByEmail.mockResolvedValue(null);157158 const result = await authService.authenticate('none@example.com', 'pass');159160 expect(result.success).toBe(false);161 expect(result.error).toBe('INVALID_CREDENTIALS');162 });163});164```165166Test requirements: $ARGUMENTS