mirror of
https://github.com/duthaho/claudekit.git
synced 2026-06-10 12:14:57 +03:00
2.7 KiB
2.7 KiB
/tdd - Test-Driven Development Workflow
Purpose
Start a TDD workflow: write failing tests first, then implement to make them pass.
Usage
/tdd [feature or function description]
Start TDD workflow for: $ARGUMENTS
Workflow
Phase 1: Red - Write Failing Tests
-
Understand Requirements
- What should the code do?
- What are the inputs/outputs?
- What edge cases exist?
-
Write Tests First
def test_feature_does_expected_thing(): result = feature("input") assert result == "expected" -
Run Tests (Expect Failure)
pytest -v # Should fail
Phase 2: Green - Make Tests Pass
-
Implement Minimal Code
- Just enough to pass tests
- No premature optimization
-
Run Tests (Expect Success)
pytest -v # Should pass
Phase 3: Refactor
-
Improve Code Quality
- Clean up implementation
- Remove duplication
- Improve naming
-
Run Tests (Ensure Still Passing)
pytest -v # Should still pass
Phase 4: Repeat
Add more test cases and repeat the cycle.
TDD Best Practices
- Write one test at a time
- Tests should be specific and focused
- Keep the red-green-refactor cycle short
- Commit after each green phase
Superpowers TDD Methodology
Reference: .claude/skills/test-driven-development/SKILL.md
Non-Negotiable Rule
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
This is not a guideline - it's a rule.
If You Already Wrote Code
Delete it. Completely. Don't keep it as reference.
WRONG: "I'll keep this code as reference while writing tests"
RIGHT: Delete the code, write test, rewrite implementation
Verification Before Completion
Reference: .claude/skills/verification-before-completion/SKILL.md
Before claiming tests pass:
- Identify the command that proves assertion
- Execute it fully and freshly
- Read complete output
- Verify output matches claim
- Only then make the claim
Forbidden Language
Never use without verification:
- "should work"
- "probably fixed"
- "seems to pass"
Testing Anti-Patterns to Avoid
Reference: .claude/skills/testing-anti-patterns/SKILL.md
- Testing mock behavior instead of real code
- Polluting production with test-only methods
- Mocking without understanding dependencies
- Creating incomplete mocks
- Writing tests as afterthoughts
Output
## TDD Session: [Feature]
### Tests Written
1. `test_basic_functionality` - [description]
2. `test_edge_case` - [description]
### Implementation
`src/feature.py` - [description]
### Cycle Summary
- Red: 3 tests written
- Green: All passing
- Refactor: Extracted helper function