tdd

# Test-Driven Development Skill

Guidelines for effective Test-Driven Development.

## TDD Philosophy

> "Write a failing test before you write the code that makes it pass."
> - Kent Beck

## The TDD Cycle

```
    ┌─────────┐
    │   RED   │  Write failing test
    └────┬────┘
         │
    ┌────▼────┐
    │  GREEN  │  Write minimal code to pass
    └────┬────┘
         │
    ┌────▼────┐
    │REFACTOR │  Clean up, keep tests green
    └────┬────┘
         │
         └──────► Repeat
```

## RED Phase

### Goal
Write a test that FAILS because the code does not exist yet.

### Rules
- Test expresses expected behavior
- Test is focused on ONE thing
- Test has meaningful assertions
- Test MUST fail when run

### If Test Passes in RED
Something is wrong:
- Code may already exist
- Test may be incorrectly written
- Test may not be testing what you think

**Investigate before proceeding.**

## GREEN Phase

### Goal
Write the MINIMUM code to make the test pass.

### Rules
- Only write enough to pass the test
- No optimization
- No additional features
- No "while I'm here" changes
- Ugly code is OK

### Mantra
"Make it work, make it right, make it fast."
(We're in "make it work" phase)

## REFACTOR Phase

### Goal
Improve code quality while keeping tests green.

### Rules
- Run tests after EVERY change
- Small, incremental improvements
- Revert if tests fail
- Stop when code is clean enough

### Common Refactorings
- Extract method/function
- Rename for clarity
- Remove duplication
- Apply design patterns
- Add documentation

## Framework-Specific Guides

- [Laravel Testing](references/laravel-testing.md)
- [Flutter Testing](references/flutter-testing.md)
- [Vue Testing](references/vue-testing.md)

## When to Use TDD

### Always Use TDD For
- Business logic
- Data transformations
- Validation rules
- API endpoints
- Services

### Consider Skipping TDD For
- Simple CRUD (test at integration level)
- Configuration code
- Boilerplate/scaffolding
- UI-only changes (use manual t