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

Step 1: Check for implementation code

Prompt: Are you about to write implementation code?

Fail: Go to Step 6

Step 2: Check for prototype exception

Prompt: Does throwaway prototype exception apply (user approved)?

Pass: Go to Step 6

Step 3: Check for failing test

Prompt: Does a failing test exist for this code?

Pass: Go to Step 6 Fail: Go to Step 4

Step 4: Write failing test first

Prompt: STOP writing implementation code. Write failing test first.

Step 5: Verify test fails

Pass: Go to Step 6 Fail: Go to Step 2

mise run test

Step 6: Proceed with implementation

Prompt: Test exists OR not writing code OR approved exception - proceed

Recovery Algorithm: Already Wrote Code Without Tests?

Step 7: Check for implementation code

Prompt: Have you written ANY implementation code?

Fail: Go to Step 11

Step 8: Check for tests

Prompt: Does that code have tests that failed first?

Pass: Go to Step 11

Step 9: Delete untested code

Prompt: Delete the untested code. Execute: git reset --hard OR rm [files]. Do not keep as "reference".

STOP

Step 10: [UNREACHABLE - Step 9 has STOP]

Step 11: Continue

Prompt: 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:

• ${SUPERPOWERS_SKILLS_ROOT}/skills/testing/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/meta/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/meta/algorithmic-command-enforcement/SKILL.md

TDD methodology: ${SUPERPOWERS_SKILLS_ROOT}/skills/testing/test-driven-development/SKILL.md

Testing anti-patterns: ${SUPERPOWERS_SKILLS_ROOT}/skills/testing/testing-anti-patterns/SKILL.md