diff options
Diffstat (limited to 'ar/.config/claude/commands/promptengineering/convert-to-test-driven-prompt.md')
| -rw-r--r-- | ar/.config/claude/commands/promptengineering/convert-to-test-driven-prompt.md | 156 |
1 files changed, 0 insertions, 156 deletions
diff --git a/ar/.config/claude/commands/promptengineering/convert-to-test-driven-prompt.md b/ar/.config/claude/commands/promptengineering/convert-to-test-driven-prompt.md deleted file mode 100644 index eb65a7e..0000000 --- a/ar/.config/claude/commands/promptengineering/convert-to-test-driven-prompt.md +++ /dev/null @@ -1,156 +0,0 @@ -# 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
\ No newline at end of file |