Loading...
Loading...
TDD workflow guide. Use PROACTIVELY when writing new features or fixing bugs. Enforces Red-Green-Refactor cycle and prevents testing anti-patterns.
npx skill4agent add carvalab/k-skills test-driven-developmentRelated Skills:
kavak-documentation- Use
MCP tool for testing best practices at Kavakkavak-platform/plati_query
# 1. Write failing test first
# 2. Run to see it fail (RED)
# 3. Write minimal code to pass (GREEN)
# 4. Refactor while tests pass (REFACTOR)
# 5. Repeat| Language | Run Tests | Watch Mode |
|---|---|---|
| Go | | |
| Node/TS | | |
| Python | | |
| Java | | |
- Write ONE test for the next piece of behavior
- Test must fail for the RIGHT reason
- Use descriptive names: should_calculate_total_with_tax
- Follow Arrange-Act-Assert structure- Write MINIMAL code to pass the test
- Don't optimize, don't refactor, don't add features
- "Fake it till you make it" is valid
- The goal is GREEN, not perfect- Clean up code while tests stay green
- Remove duplication
- Improve names
- Extract methods/functions
- Run tests after EVERY change| Rationalization | Counter |
|---|---|
| "Let me just write one more method" | Stop. Test what exists first |
| "I'll add tests after" | You won't. Tests written after verify nothing |
| "It's too simple to test" | Simple now, complex later. Test it |
| "I'll refactor tests later" | Refactor production code, not test structure |
| "This is just scaffolding" | Scaffolding becomes foundation. Test it |
| Anti-Pattern | Problem | Fix |
|---|---|---|
| The Liar | Test passes but tests nothing | Assert actual behavior |
| The Mockery | Over-mocking hides real bugs | Mock boundaries only |
| Excessive Setup | 50 lines setup, 2 lines test | Simplify SUT or use builders |
| The Slow Poke | Tests take minutes | Isolate, mock I/O |
| The Local Hero | Passes locally, fails in CI | No env dependencies |
| Test-per-Method | 1:1 test-to-method | Test behaviors, not methods |
[ ] Test fails when behavior is removed?
[ ] Test name describes the behavior?
[ ] Arrange-Act-Assert structure clear?
[ ] No test-only code in production?
[ ] Mocks verify behavior, not implementation?
[ ] Edge cases covered?should_[expected_behavior]_when_[condition]
Examples:
- should_return_zero_when_cart_is_empty
- should_throw_error_when_user_not_found
- should_apply_discount_when_coupon_valid| Reference | Purpose |
|---|---|
| Detailed cycle walkthrough |
| Full anti-pattern catalog |
| Go TDD examples |
| Node/TypeScript TDD examples |
| Python TDD examples |
| Java TDD examples |
| Pre-commit verification |
| What to mock, what not to mock |