red

name	red
description	TDD Red Phase - Activate ONE test from the test list and make it fail with explicit predictions

TDD Red Phase

You are now in the Red Phase of TDD. Follow these instructions to activate ONE test and make it fail.

Your Mission

Guide developers through the Red phase of TDD by helping them:

1. Activate exactly ONE test from the test list
2. Make explicit predictions about how the test will fail
3. Verify the test fails for the right reason (compilation error, then runtime error)
4. Maintain strict TDD discipline - no implementation during Red phase

Context: $ARGUMENTS

Red Phase Rules

• One test at a time: Convert exactly ONE it.todo() to executable test code
• All other tests remain as it.todo(): Never have more than one failing test
• Two-stage failure: First compilation error, then runtime/assertion error
• Make predictions: Explicitly state expected failures before running tests
• No implementation: Don't write code to make test pass yet

Red Phase Process

Step 1: Activate One Test

• Identify the next it.todo() from the test list
• Convert it to executable test code
• Leave all other tests as it.todo()
• Ensure only one test is active/failing

Step 2: Make Prediction (Guessing Game) - Compilation Error

Before running the test, explicitly state:

• Which test will fail
• Type of error: Compilation error
• Reason: Function doesn't exist yet
• Expected error message (TypeScript/compiler error)

Example prediction:

Red Phase - Compilation Error Prediction:
- Test: "should return 0 for empty input"
- Expected: Compilation error
- Reason: Function `calculate` doesn't exist yet
- Error: "Cannot find name 'calculate'"

Step 3: Run Test - Verify Compilation Error

• Run the test
• Verify it fails with compilation error as predicted
• If prediction was wrong, STOP and explain discrepancy

Step 4: Create Empty Function

• Create function signature with minimal implementation
• Function should return undefined, wrong type, or wrong value
• No actual logic yet

Step 5: Make Prediction - Runtime Error

Before running the test again, explicitly state:

• Which test will fail
• Type of error: Runtime/assertion error
• Expected value (what test expects)
• Actual value (what function will return)
• Expected diff output

Example prediction:

Red Phase - Runtime Error Prediction:
- Test: "should return 0 for empty input"
- Expected: Runtime assertion error
- Expected value: 0
- Actual value: undefined
- Diff:
  Expected: 0
  Received: undefined

Step 6: Run Test - Verify Runtime Error

• Run the test
• Verify it fails with assertion error as predicted
• If prediction was wrong, STOP and explain discrepancy

Step 7: Report Completion

You MUST output the full Step 7 block verbatim with Correct or Incorrect chosen for each prediction. Do not abbreviate. Do not collapse the two prediction lines into one.

Red Phase Complete:
**Test Activated**: "should return 0 for empty input"
**Compilation Prediction**: Cannot find name 'calculate' ✅ Correct
**Runtime Prediction**: Expected 0, received undefined ✅ Correct
**Result**: Test fails as expected with assertion error

Proceeding to Green phase.

Important Guidelines

What to DO

• Activate exactly ONE test at a time
• Make explicit predictions before running tests
• Verify test fails for the right reason
• Explain if predictions fail
• Keep all other tests as it.todo()

What NOT to do

• Never activate multiple tests simultaneously
• Never skip making predictions
• Never write implementation to make test pass
• Never continue if prediction fails without explanation
• Never implement beyond creating empty function

Psychological Resistance

Developers will experience resistance:

• Feels uncomfortable - This is normal and correct
• Seems wasteful - Two-stage failure seems redundant but builds understanding
• Urge to implement - Strong desire to fix the test immediately
• Push through discomfort - These feelings indicate correct discipline

Red Flags

Watch for these violations:

• Multiple active tests (not it.todo())
• Skipping predictions
• Writing implementation before test fails
• Not verifying test actually fails
• Ignoring failed predictions

Output Format

When Activating Test

// Convert from:
it.todo("should return 0 for empty input");

// To:
it("should return 0 for empty input", () => {
  expect(calculate([])).toBe(0);
});

Prediction Template - Compilation Error

Red Phase - Compilation Error Prediction:
- Test: [test name]
- Expected: Compilation error
- Reason: [why it will fail]
- Error: [expected error message]

Prediction Template - Runtime Error

Red Phase - Runtime Error Prediction:
- Test: [test name]
- Expected: Runtime assertion error
- Expected value: [expected]
- Actual value: [actual]
- Diff: [expected diff output]

Completion Template

Red Phase Complete:
**Test Activated**: [test name]
**Compilation Prediction**: [error message] ✅ Correct / ❌ Incorrect
**Runtime Prediction**: [error message] ✅ Correct / ❌ Incorrect
**Result**: [actual result]

Proceeding to Green phase.

Remember

• One test at a time - Never more than one active test
• Predictions are mandatory - Build understanding through explicit expectations
• Two-stage failure - Compilation error, then runtime error
• No implementation - Only create empty function signature
• Trust the process - Discomfort indicates correct discipline

Your goal is to maintain strict TDD discipline, ensure predictions are made and verified, and proceed autonomously through the TDD cycle.