Use when writing production code. Enforces RED-GREEN-REFACTOR cycle: write failing test, make it pass, improve design. Prevents test-after development and ensures verified behavior.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Use when writing production code. Enforces RED-GREEN-REFACTOR cycle: write failing test, make it pass, improve design. Prevents test-after development and ensures verified behavior.
Refactor Phase Complete When: Code is clean AND tests still pass
Anti-patterns Table
Anti-pattern
✗ Wrong Approach
✓ Correct TDD Approach
Test-After
Write calculateTotal() function, then write tests
Write test for calculateTotal(), see it fail, implement function
Empty Tests
Write test that always passes: expect(true).toBe(true)
Write test that fails until production code is correct
Happy-Path-Only
Test only valid inputs: validateEmail('user@example.com')
Test invalid inputs too: validateEmail('no-at-sign'), validateEmail('')
Skip-Simple
Skip test for "obvious" add(a, b) { return a + b }
Write test: expect(add(2, 3)).toBe(5) - bugs hide in "simple" code
Change-Then-Test
Modify calculateDiscount(), run app manually, then add test
Write failing test showing bug, modify code until test passes
Testing Strategy by Code Type
Pure Functions
Pattern: 1 happy path + 3 edge cases minimum
Example (TypeScript):
describe('calculateDiscount', () => {
it('applies 10% discount to $100 purchase', () => {
expect(calculateDiscount(100, 0.1)).toBe(90);
});
it('returns 0 for negative amounts', () => {
expect(calculateDiscount(-50, 0.1)).toBe(0);
});
it('returns original amount for 0 discount', () => {
expect(calculateDiscount(100, 0)).toBe(100);
});
it('throws error for discount > 1', () => {
expect(() =>calculateDiscount(100, 1.5)).toThrow('Discount must be <= 1');
});
});
Error Handlers
Pattern: 1 test per error type + 1 success case
Example (Python/pytest):
deftest_divide_by_zero_raises_error():
with pytest.raises(ZeroDivisionError, match="Cannot divide by zero"):
divide(10, 0)
deftest_divide_non_numeric_raises_error():
with pytest.raises(TypeError, match="Arguments must be numbers"):
divide("10", 5)
deftest_divide_returns_float():
result = divide(10, 3)
assert result == pytest.approx(3.333, rel=1e-3)
Objection: "TDD is too slow, I can code faster without tests"
Response: Writing tests first actually saves time by catching bugs early. Debugging later is far more expensive than preventing bugs upfront.
Objection: "This code is too simple to test"
Response: Simple code is fastest to test. If it's truly simple, the test takes 30 seconds. If you can't write a fast test, the code isn't simple.
Objection: "I'll write tests after I figure out the design"
Response: Tests ARE the design. Writing tests first forces you to think about API usability before implementation locks you in.
Objection: "I need to see if my approach works before committing to tests"
Response: That's what the RED phase is for - write a test describing your desired approach, then implement it. If approach changes, update test first.