blob: eb65a7e96b6d4af2d1826152272812147d8a0e3e (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
# Convert to Test-Driven Prompt
Transform user requests into Test-Driven Development (TDD) style prompts that explicitly define expected outcomes, test cases, and success criteria before implementation.
## Usage Examples
### Basic Usage
"Convert this to TDD: Add a user authentication feature"
"Make this test-driven: Create a shopping cart component"
"TDD version: Implement data validation for the form"
### With File Input
`/convert-to-test-driven-prompt @path/to/prompt-file.md`
`/convert-to-test-driven-prompt @../other-project/feature-request.txt`
### Complex Scenarios
"Convert to TDD: Refactor the payment processing module"
"Test-driven approach for: API rate limiting feature"
"TDD prompt for: Database migration script"
## Instructions for Claude
When converting to TDD prompts:
### Input Handling
- If `$ARGUMENTS` is provided, read the file at that path to get the prompt to convert
- If no `$ARGUMENTS`, use the user's direct input as the prompt to convert
- Support relative and absolute file paths
1. **Extract Requirements**: Identify core functionality from the original request
2. **Define Test Cases**: Create specific, measurable test scenarios
3. **Specify Expected Outcomes**: Clear success and failure criteria
4. **Structure for Implementation**: Organize prompt for red-green-refactor cycle
5. **Include Edge Cases**: Don't forget boundary conditions and error scenarios
### TDD Prompt Structure
#### 1. Objective Statement
Clear, concise description of what needs to be built
#### 2. Test Specifications
```
GIVEN: [Initial state/context]
WHEN: [Action performed]
THEN: [Expected outcome]
```
#### 3. Success Criteria
- Specific, measurable outcomes
- Performance requirements
- Error handling expectations
- Edge case behaviors
#### 4. Test Cases Format
```markdown
Test Case 1: [Descriptive name]
- Input: [Specific input data]
- Expected Output: [Exact expected result]
- Validation: [How to verify success]
Test Case 2: [Edge case name]
- Input: [Boundary/error condition]
- Expected Output: [Error handling result]
- Validation: [Error verification method]
```
### Conversion Examples
#### Original Request:
"Add user login functionality"
#### TDD Conversion:
```markdown
## Objective
Implement secure user login with email/password authentication
## Test Specifications
### Test 1: Successful Login
GIVEN: Valid user credentials exist in database
WHEN: User submits correct email and password
THEN: User receives auth token and is redirected to dashboard
### Test 2: Invalid Password
GIVEN: Valid email but incorrect password
WHEN: User submits login form
THEN: Return error "Invalid credentials" without revealing which field is wrong
### Test 3: Non-existent User
GIVEN: Email not in database
WHEN: User attempts login
THEN: Return same "Invalid credentials" error (prevent user enumeration)
### Test 4: Rate Limiting
GIVEN: User has failed 5 login attempts
WHEN: User attempts 6th login within 15 minutes
THEN: Block attempt and show "Too many attempts" error
## Success Criteria
- All tests pass
- Password is hashed using bcrypt
- Auth tokens expire after 24 hours
- Login attempts are logged
- Response time < 200ms
```
### Output Format
Generate TDD prompt as:
```markdown
## TDD Prompt: [Feature Name]
### Objective
[Clear description of the feature to implement]
### Test Suite
#### Happy Path Tests
[List of successful scenario tests]
#### Error Handling Tests
[List of failure scenario tests]
#### Edge Case Tests
[List of boundary condition tests]
### Implementation Requirements
- [ ] All tests must pass
- [ ] Code coverage > 80%
- [ ] Performance criteria met
- [ ] Security requirements satisfied
### Test-First Development Steps
1. Write failing test for [first requirement]
2. Implement minimal code to pass
3. Refactor while keeping tests green
4. Repeat for next requirement
### Example Test Implementation
```language
// Example test code structure
describe('FeatureName', () => {
it('should [expected behavior]', () => {
// Test implementation
});
});
```
```
Remember to:
- Focus on behavior, not implementation details
- Make tests specific and measurable
- Include both positive and negative test cases
- Consider performance and security in tests
- Structure for iterative TDD workflow
|
