tdd

测试驱动开发方法与模式。触发条件：“TDD”、“先写测试”、“失败的测试”、“红绿重构”、“测试驱动”、“先测试”、“覆盖率”、“单元测试”、“功能测试”、“组件测试”。为 Laravel（PHPUnit/Pest）、Flutter，以及 Vue（Vitest/Jest）提供 TDD 模式。

SKILL.md

--- frontmatter

name: tdd
description: |
  Test-Driven Development methodology and patterns. Triggers on: "tdd", "test first",
  "write tests", "failing test", "red green refactor", "test driven", "test before",
  "coverage", "unit test", "feature test", "widget test".

  Provides TDD patterns for Laravel (PHPUnit/Pest), Flutter, and Vue (Vitest/Jest).

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

code

    ┌─────────┐
    │   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

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 testing)

Test Types

Type	Tests	Speed	Confidence
Unit	Single class/function	Fast	Low
Integration	Multiple components	Medium	Medium
Feature/E2E	Full flow	Slow	High

Test Pyramid

code

        /\
       /  \      E2E Tests (few)
      /----\
     /      \    Integration Tests (some)
    /--------\
   /          \  Unit Tests (many)
  /____________\

Coverage Targets

Area	Minimum	Target
Business Logic	90%	100%
Services	85%	95%
Controllers	80%	90%
UI Components	70%	85%

Anti-Patterns

Test After

Writing tests after implementation - you lose the design benefits of TDD.

Testing Implementation

Testing HOW code works instead of WHAT it does.

Over-Mocking

Mocking everything - you're testing your mocks, not your code.

Giant Tests

Tests that test too much - hard to debug when they fail.

Flaky Tests

Tests that sometimes pass, sometimes fail - erode trust in test suite.

Quick Reference

RED Phase Checklist

• Test has descriptive name
• Test is focused on ONE behavior
• Test has clear assertion
• Test FAILS when run

GREEN Phase Checklist

• Code is minimal
• No extra features
• Test PASSES
• No new tests written

REFACTOR Phase Checklist

• Code is cleaner
• Tests still PASS
• No behavior changed
• Ready for next cycle