| name | TDD Enforcement Algorithm |
| description | Algorithmic decision tree enforcing test-first development via boolean conditions instead of imperatives |
| when_to_use | when about to write implementation code, to determine if failing test must be written first, or when code exists without tests to determine if deletion required |
| version | 1.0.0 |
TDD Enforcement Algorithm
Overview
Agents follow algorithmic decision trees (100% compliance) better than imperative instructions (0-33% compliance) for enforcing test-first development. Boolean conditions remove interpretation: "Does failing test exist? NO → STOP" vs "You MUST write tests first" (agent: "for complex code, mine is simple").
Core principle: Binary checks before implementation. Recovery mandates deleting untested code (no sunk cost exceptions).
When to Use
Use this algorithm when:
- About to write implementation code (functions, methods, classes)
- Code exists without tests (recovery path)
- Under pressure (time, sunk cost, authority) where TDD bypass tempting
- Need deterministic enforcement (no acceptable exceptions)
Use upstream TDD skill when:
- This algorithm says proceed (test exists, now implement)
- Learning RED-GREEN-REFACTOR methodology
- Understanding why TDD matters
Relationship:
- This skill: WHEN to use TDD (decision algorithm)
- Upstream skill: HOW to use TDD (implementation details)
Decision Algorithm: When to Write Tests First
1. Check for implementation code
Are you about to write implementation code?
- PASS: CONTINUE
- FAIL: GOTO 6
2. Check for prototype exception
Does throwaway prototype exception apply (user approved)?
- PASS: GOTO 6
- FAIL: CONTINUE
3. Check for failing test
Does a failing test exist for this code?
- PASS: GOTO 6
- FAIL: CONTINUE
4. Write failing test first
STOP writing implementation code. Write failing test first.
5. Verify test fails
Run project test command
- PASS (test runs and fails as expected): GOTO 6
- FAIL (test passes or doesn't run): GOTO 4 (fix test)
6. Proceed with implementation
Test exists OR not writing code OR approved exception - proceed
Recovery Algorithm: Already Wrote Code Without Tests?
7. Check for implementation code
Have you written ANY implementation code?
- PASS: CONTINUE
- FAIL: GOTO 10
8. Check for tests
Does that code have tests that failed first?
- PASS: GOTO 10
- FAIL: CONTINUE
9. Delete untested code
Delete the untested code. Execute: git reset --hard OR rm [files]. Do not keep as "reference".
10. Continue
Tests exist OR no code written - continue
INVALID Conditions (NOT in algorithm, do NOT use)
These rationalizations are NOT VALID ALGORITHM CONDITIONS:
- "Is code too simple to test?" → NOT A VALID CONDITION
- "Is there time pressure?" → NOT A VALID CONDITION
- "Did I manually test it?" → NOT A VALID CONDITION
- "Will I add tests after?" → NOT A VALID CONDITION
- "Is deleting X hours wasteful?" → NOT A VALID CONDITION
- "Am I being pragmatic?" → NOT A VALID CONDITION
- "Can I keep as reference?" → NOT A VALID CONDITION
- "Is this exploratory code?" → NOT A VALID CONDITION (ask for throwaway prototype exception)
- "Tests after achieve same goal?" → NOT A VALID CONDITION
- "I already know it works?" → NOT A VALID CONDITION
All of these mean: Run the algorithm. Follow what it says.
Self-Test
Q1: You're about to write function calculateTotal(). What does Step 3 ask?
Answer: "Does a failing test exist?" If NO → Go to Step 4 (STOP, write test first)
Q2: I wrote 100 lines without tests. What does Recovery Step 3 say?
Answer: Delete the untested code. Execute: git reset --hard OR rm [files]
Q3: "This code is too simple to need tests" - is this a valid algorithm condition?
Answer: NO. Listed under INVALID conditions
Q4: Can I keep untested code as "reference" while writing tests?
Answer: NO. Recovery Step 3 says "Delete... Do not keep as 'reference'"
Five Mechanisms That Work
1. Boolean Conditions (No Interpretation)
Imperative: "You MUST write tests first"
Agent rationalization: "For complex code. Mine is simple."
Algorithmic: "Does a failing test exist? → YES/NO"
Agent: Binary check. Either test exists or it doesn't. No interpretation.
2. Explicit Invalid Conditions List
Imperative: "Regardless of simplicity or time pressure..."
Agent: Still debates what "simple" means
Algorithmic: "Is code too simple to test?" → NOT A VALID CONDITION
Agent: Sees rationalization explicitly invalidated. Can't use it.
3. Deterministic Execution Path with STOP
Imperative: Multiple MUST statements → agent balances priorities
Algorithmic:
Step 4: STOP writing implementation code
Write failing test first
Result: Single path. No choices. STOP prevents continuing.
4. Self-Test Forcing Comprehension
Quiz with correct answers:
Q1: About to write function. Step 3 asks?
Answer: Does a failing test exist?
Agents demonstrate understanding before proceeding. Catches comprehension failures early.
5. Unreachable Steps Proving Determinism
Step 5: [UNREACHABLE - if you reach here, you violated Step 4]
Demonstrates algorithm is deterministic. Reaching Step 5 = violation.
Real-World Impact
Evidence from algorithmic-command-enforcement pattern:
- Imperative "MUST" language: 0-33% compliance under pressure
- Same content, algorithmic format: 100% compliance
- Pressure scenarios: time deadline + sunk cost + authority combined
Agent quotes (from /execute command testing):
"The algorithm successfully prevented me from rationalizing..."
"Non-factors correctly ignored: ❌ 2 hours sunk cost, ❌ Exhaustion"
"Step 2: Does code have tests? → NO. Step 3: Delete the untested code"
Common Failure Modes Prevented
| Rationalization | How Algorithm Prevents |
|---|
| "Too simple for tests" | NOT A VALID CONDITION - Step 3 checks test existence, not code complexity |
| "Deleting X hours wasteful" | NOT A VALID CONDITION - Recovery Step 3 mandates delete unconditionally |
| "Will add tests after" | NOT A VALID CONDITION - Step 4 requires test FIRST (not after) |
| "Manual testing sufficient" | NOT A VALID CONDITION - Step 3 checks "failing test exists", not "tested somehow" |
| "Time pressure exception" | NOT A VALID CONDITION - Time not in algorithm, only user-approved prototype exception |
| "Keep as reference" | Recovery Step 3 explicit: "Do not keep as 'reference'" |
Integration with TDD Methodology
This algorithm provides: WHEN to write tests (before implementation)
For complete TDD methodology, see:
${CLAUDE_PLUGIN_ROOT}skills/test-driven-development/SKILL.md
- RED-GREEN-REFACTOR cycle
- How to write failing tests
- How to write minimal implementation
- What makes good tests
- Verification checklist
Workflow:
- This algorithm → Confirms test required before coding
- Upstream TDD skill → Shows how to write the test, implement, refactor
Why Algorithmic Format
Previous approach (imperative):
"Write the test first. Watch it fail. Write minimal code to pass.
The Iron Law: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST"
Problem: Agents acknowledged then rationalized bypass:
- "This is different because..." (simplicity, time, manual testing)
- "I'll test after - achieves same goal"
- "Deleting is wasteful"
Solution: Algorithm with binary conditions. No subjective interpretation possible.
Evidence: Based on plugin/skills/algorithmic-command-enforcement/SKILL.md pattern showing 0% → 100% compliance improvement.
Testing
Pressure test scenarios: docs/tests/tdd-enforcement-pressure-scenarios.md
Scenarios test algorithm under:
- Simple bug fix + time pressure ("too simple for test")
- Complex feature + sunk cost ("deleting is wasteful")
- Production hotfix + authority ("CTO says skip tests")
Method: RED (baseline without algorithm) → GREEN (with algorithm) → measure compliance
Success criteria: 80%+ compliance improvement
Related Skills
Algorithmic pattern: plugin/skills/algorithmic-command-enforcement/SKILL.md
TDD methodology: ${CLAUDE_PLUGIN_ROOT}skills/test-driven-development/SKILL.md
Testing anti-patterns: ${CLAUDE_PLUGIN_ROOT}skills/testing-anti-patterns/SKILL.md
