Back to Details

test-driven-development

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Test-Driven Development

测试驱动开发（Test-Driven Development）

Part of Agent Skills™ by googleadsagent.ai™
本内容属于 Agent Skills™，由 googleadsagent.ai™ 提供

Description

描述

Test-Driven Development enforces the RED-GREEN-REFACTOR discipline on every code change an agent produces. The agent writes a failing test first, confirms the failure, writes the minimal code to pass, confirms the pass, refactors for clarity, and commits. No production code exists without a corresponding test that demanded its creation.
This skill eliminates the most common agent anti-pattern: generating large blocks of untested code that "look right" but silently break under edge cases. By forcing the agent through the TDD cycle, each line of production code is justified by a specific test assertion. The result is a codebase where test coverage is not an afterthought but a structural guarantee.
The cycle integrates directly with version control. Each RED-GREEN-REFACTOR iteration produces an atomic commit, creating a reviewable history of design decisions. The refactor phase is mandatory—the agent must evaluate naming, duplication, and structural clarity before moving to the next feature increment.
测试驱动开发（Test-Driven Development）要求Agent生成的每一处代码变更都遵循RED-GREEN-REFACTOR准则。Agent首先编写一个失败的测试用例，确认测试失败，然后编写最少的代码让测试通过，确认测试通过，接着为了代码清晰性进行重构，最后提交代码。不存在没有对应测试用例的生产代码——所有生产代码的创建都由测试用例驱动。
这项技能消除了Agent最常见的反模式：生成大量未经测试的代码，这些代码“看起来没问题”，但在边缘场景下会悄然崩溃。通过强制Agent遵循TDD循环，每一行生产代码都有明确的测试断言作为依据。最终得到的代码库中，测试覆盖率不是事后补充的，而是结构化的保障。
该循环直接与版本控制集成。每一次RED-GREEN-REFACTOR迭代都会生成一个原子提交，形成可追溯的设计决策历史。重构阶段是强制性的——Agent在进入下一个功能增量前，必须评估命名、重复代码和结构清晰度。

Use When

使用场景

  • Writing any new function, method, or module
  • Fixing a bug (write the test that exposes the bug first)
  • Refactoring existing code (ensure tests pass before and after)
  • The user requests "TDD", "test-first", or "red-green-refactor"
  • Building APIs, data transformations, or business logic
  • You need confidence that a change does not introduce regressions
  • 编写任何新函数、方法或模块时
  • 修复Bug时（先编写能暴露Bug的测试用例）
  • 重构现有代码时（确保重构前后测试都能通过）
  • 用户要求“TDD”、“测试优先”或“red-green-refactor”时
  • 构建API、数据转换或业务逻辑时
  • 需要确保变更不会引入回归问题时

How It Works

工作原理

mermaid
graph LR
    R[RED: Write Failing Test] --> G[GREEN: Minimal Code to Pass]
    G --> RF[REFACTOR: Clean Up]
    RF --> C[COMMIT: Atomic Commit]
    C --> R
    style R fill:#e74c3c,color:#fff
    style G fill:#2ecc71,color:#fff
    style RF fill:#3498db,color:#fff
    style C fill:#95a5a6,color:#fff
RED: Write a test that describes the next small behavior increment. Run it. Confirm it fails for the expected reason—not a syntax error or import failure, but a genuine assertion failure. GREEN: Write the simplest production code that makes the test pass. Resist the urge to generalize. REFACTOR: Improve names, extract duplication, simplify control flow. All tests must still pass. COMMIT: Stage and commit with a message referencing the behavior added.
mermaid
graph LR
    R[RED: Write Failing Test] --> G[GREEN: Minimal Code to Pass]
    G --> RF[REFACTOR: Clean Up]
    RF --> C[COMMIT: Atomic Commit]
    C --> R
    style R fill:#e74c3c,color:#fff
    style G fill:#2ecc71,color:#fff
    style RF fill:#3498db,color:#fff
    style C fill:#95a5a6,color:#fff
RED：编写一个描述下一个小型行为增量的测试用例。运行测试，确认测试因预期原因失败——不是语法错误或导入失败，而是真正的断言失败。GREEN：编写最简单的生产代码让测试通过。克制过度泛化的冲动。REFACTOR：优化命名、提取重复代码、简化控制流。所有测试必须仍能通过。COMMIT：暂存并提交代码，提交信息需关联新增的行为。

Implementation

实现示例

python
undefined
python
undefined

RED: Write the failing test first

RED: Write the failing test first

def test_calculate_discount_applies_ten_percent_for_orders_over_100(): order = Order(items=[Item(price=150.00)]) result = calculate_discount(order) assert result == 135.00 # 10% off
def test_calculate_discount_applies_ten_percent_for_orders_over_100(): order = Order(items=[Item(price=150.00)]) result = calculate_discount(order) assert result == 135.00 # 10% off

Run: pytest => FAIL (calculate_discount not defined)

Run: pytest => FAIL (calculate_discount not defined)

GREEN: Minimal implementation

GREEN: Minimal implementation

def calculate_discount(order): total = sum(item.price for item in order.items) if total > 100: return total * 0.9 return total
def calculate_discount(order): total = sum(item.price for item in order.items) if total > 100: return total * 0.9 return total

Run: pytest => PASS

Run: pytest => PASS

REFACTOR: Extract magic numbers

REFACTOR: Extract magic numbers

DISCOUNT_THRESHOLD = 100 DISCOUNT_RATE = 0.10
def calculate_discount(order): total = sum(item.price for item in order.items) if total > DISCOUNT_THRESHOLD: return total * (1 - DISCOUNT_RATE) return total
DISCOUNT_THRESHOLD = 100 DISCOUNT_RATE = 0.10
def calculate_discount(order): total = sum(item.price for item in order.items) if total > DISCOUNT_THRESHOLD: return total * (1 - DISCOUNT_RATE) return total

Run: pytest => PASS

Run: pytest => PASS

git commit -m "feat: apply 10% discount for orders over $100"

git commit -m "feat: apply 10% discount for orders over $100"

undefined
undefined

Anti-Patterns to Avoid

需避免的反模式

Anti-PatternWhy It Fails
Writing tests after codeTests confirm assumptions, not behavior
Testing implementation detailsBrittle tests break on valid refactors
Skipping the RED stepNo proof the test can actually fail
Large GREEN stepsLose traceability of which test drives which code
Skipping REFACTORTechnical debt accumulates silently
反模式失败原因
先写代码再写测试测试只是验证假设，而非行为
测试实现细节脆弱的测试会在合理重构时失败
跳过RED阶段无法证明测试确实能检测到失败
GREEN阶段代码量过大失去测试与代码的可追溯性
跳过REFACTOR阶段技术债会悄然累积

Best Practices

最佳实践

  • Each RED-GREEN-REFACTOR cycle should take under 5 minutes
  • If GREEN requires more than 10 lines, the test is too ambitious—split it
  • Name tests as behavior specifications: 
    test_<action>_<condition>_<outcome>
  • Run the full test suite after every REFACTOR, not just the new test
  • Commit after each complete cycle to preserve the design narrative
  • Use test doubles (mocks, stubs) only at architectural boundaries
  • 每一次RED-GREEN-REFACTOR循环应控制在5分钟以内
  • 如果GREEN阶段需要编写超过10行代码，说明测试目标过于宏大——拆分测试
  • 测试用例命名应体现行为规范：
    test_<动作>_<条件>_<结果>
  • 每次REFACTOR后运行完整测试套件，而非仅运行新测试
  • 每个完整循环后提交代码，以保留设计过程的可追溯性
  • 仅在架构边界使用测试替身（mocks、stubs）

Platform Compatibility

平台兼容性

PlatformSupportNotes
CursorFullShell tool runs tests inline
VS CodeFullTerminal integration for test runs
WindsurfFullCascade executes test commands
Claude CodeFullDirect shell access for pytest/jest
ClineFullConfigurable test runner
aiderPartialManual test confirmation needed
平台支持情况说明
Cursor完全支持Shell工具可在内部运行测试
VS Code完全支持终端集成可运行测试
Windsurf完全支持Cascade可执行测试命令
Claude Code完全支持可直接通过shell访问pytest/jest
Cline完全支持可配置测试运行器
aider部分支持需要手动确认测试结果

Related Skills

相关技能

  • Systematic Debugging - Root cause analysis that starts by writing a failing test reproducing the bug
  • Code Review - Quality gate that verifies test coverage alongside production code changes
  • Subagent-Driven Development - Isolated subagents that follow TDD cycles independently for each subtask
  • Systematic Debugging - 根本原因分析，从编写能复现Bug的失败测试用例开始
  • Code Review - 质量把关，在审核生产代码变更的同时验证测试覆盖率
  • Subagent-Driven Development - 独立的子Agent，针对每个子任务独立遵循TDD循环

Keywords

关键词

tdd
test-driven-development
red-green-refactor
failing-test-first
test-first
unit-testing
regression-prevention
atomic-commits
© 2026 googleadsagent.ai™ | Agent Skills™ | MIT License
tdd
test-driven-development
red-green-refactor
failing-test-first
test-first
unit-testing
regression-prevention
atomic-commits
© 2026 googleadsagent.ai™ | Agent Skills™ | MIT License