---
name: superteam-test-driven-development
description: Write failing tests before implementation code — RED, GREEN, REFACTOR
globs: "**/*.ts,**/*.tsx,**/*.js,**/*.jsx"
---

# Test-Driven Development (TDD)

## The Cycle

Every code change follows the RED → GREEN → REFACTOR cycle:

### 1. RED — Write a Failing Test
- Write a test that describes the desired behavior
- Run it — it MUST fail
- The failure message should describe what's missing
- If the test passes immediately, it's testing the wrong thing

### 2. GREEN — Write Minimal Implementation
- Write the MINIMUM code to make the test pass
- No extra features, no "while I'm here" additions
- No refactoring yet — just make it work
- Run the test — it MUST pass

### 3. REFACTOR — Clean Up
- Improve code quality without changing behavior
- ALL tests must still pass after refactoring
- Remove duplication, improve naming, simplify
- Run tests after every change

## Rules

1. **Never write implementation code without a failing test first**
2. **Write only enough test to fail** — one assertion at a time
3. **Write only enough code to pass** — resist the urge to over-engineer
4. **Run tests constantly** — after every change, not just at the end
5. **Tests are first-class code** — maintain them with the same care

## Test Quality Checklist

- [ ] Tests verify BEHAVIOR, not implementation details
- [ ] Each test has a clear, descriptive name
- [ ] Tests are independent — no shared mutable state
- [ ] Edge cases are covered: null, empty, boundary values
- [ ] Error cases are tested explicitly
- [ ] Tests run fast (< 1 second each)

## Anti-Patterns to Avoid

- ❌ Writing implementation first, then "adding tests"
- ❌ Writing multiple tests before any implementation
- ❌ Testing private methods or implementation details
- ❌ Excessive mocking — prefer real objects when possible
- ❌ "This is too simple to test" — it's not
- ❌ Copying implementation logic into test assertions

## Example Workflow

```
Feature: Add function to validate email

1. RED: Write test
   test("rejects empty string", () => {
     expect(validateEmail("")).toBe(false);
   });
   → Run → FAIL (validateEmail not defined)

2. GREEN: Implement minimally
   function validateEmail(email: string): boolean {
     return email.length > 0;
   }
   → Run → PASS

3. RED: Next test
   test("rejects string without @", () => {
     expect(validateEmail("foo")).toBe(false);
   });
   → Run → FAIL

4. GREEN: Extend implementation
   function validateEmail(email: string): boolean {
     return email.length > 0 && email.includes("@");
   }
   → Run → PASS

5. REFACTOR: (nothing to refactor yet)

6. Continue cycle for more cases...
```

## When TDD Guard is Active

The superteam extension enforces TDD mechanically:
- You cannot write to implementation files without a test file existing
- You cannot write to implementation files without tests having been run
- Test files are always writable
- Use `/tdd` to check mode, `/tdd off` to disable if needed