Skills
Enforces TDD discipline with RED-GREEN-REFACTOR cycle. Use when writing new features, fixing bugs, or refactoring code. Ensures tests genuinely verify behavior.From its SKILL.md
npx -y skills add majiayu000/spellbook --skill test-driven-developmentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
2.9 KB, 680 tokens by cl100k_base, as published. Nobody here has run it
Test-Driven Development (TDD)
From obra/superpowers
Core Principle
Write tests before implementation. Watch them fail. Write minimal code to pass.
THE IRON LAW: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
When to Apply TDD
- New features
- Bug fixes
- Refactoring
- Any behavior changes
The Red-Green-Refactor Cycle
RED: Write a Failing Test
- Write ONE minimal test demonstrating desired behavior
- Use clear, descriptive test names
- Use real code, avoid unnecessary mocks
- Test should fail for the RIGHT reason
# Verify RED
- Run the test
- Confirm it fails
- Confirm failure is NOT due to syntax errors
- Confirm you're not testing existing functionality
GREEN: Make It Pass
- Write the SIMPLEST code that makes the test pass
- Don't add extra features
- Don't optimize yet
- Just make it work
# Verify GREEN
- Run all tests
- Confirm new test passes
- Confirm no other tests broke
REFACTOR: Clean Up
- Improve code quality while keeping tests green
- Remove duplication
- Improve naming
- Extract helpers if needed
- Run tests after each change
Why This Order Matters
Tests written AFTER implementation:
- Pass immediately (proves nothing)
- You never see them fail
- Cannot verify they test what matters
- Manual testing is NOT a substitute
Common Rationalizations to REJECT
| Excuse | Reality |
|---|---|
| "Too simple to test" | Simple code still breaks |
| "I'll write tests after" | Post-implementation tests pass immediately |
| "Already manually tested" | Manual testing lacks systematic rigor |
| "Deleting work is wasteful" | Unverified code is technical debt |
| "Keep as reference" | You'll adapt it; that's testing-after |
Red Flags Requiring RESTART
If any of these occur, DELETE the code and start over:
- Writing code before tests
- Tests passing immediately on first run
- Rationalizing "just this once"
- Planning to "test later"
- Keeping pre-written code "as reference"
Example Workflow
# 1. RED - Write failing test
def test_user_can_login_with_valid_credentials():
user = create_user(email="[email protected]", password="secret")
result = login(email="[email protected]", password="secret")
assert result.success == True
assert result.user == user
# 2. Run test - MUST FAIL
# 3. GREEN - Implement minimal code
def login(email, password):
user = User.find_by_email(email)
if user and user.check_password(password):
return LoginResult(success=True, user=user)
return LoginResult(success=False, user=None)
# 4. Run test - MUST PASS
# 5. REFACTOR - Clean up if needed
Summary
- Write test first
- Watch it fail
- Write minimal code to pass
- Refactor while green
- Repeat