TDD Enforcement Algorithm

What this skill does

# 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".

- PASS: STOP
- FAIL: STOP

## 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:**
1. **This algorithm** → Confirms test required before coding
2. **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/