测试驱动开发（Test-Driven Development）是一个面向构建阶段的测试技能，核心是红-绿-重构循环：先写一个失败的测试，再写刚好能通过测试的最小实现，最后在不改变行为的前提下重构。测试被视为系统按预期行为的证明。
用途
该技能适用于以下场景：实现新的逻辑或功能；修复缺陷（先写一个能复现缺陷的失败测试）；重构既有行为；修改任何有正确性要求的代码。
主要能力
技能提供测试金字塔的分布建议：约80%为单元测试，快速、隔离，测试单个函数与组件；约15%为集成测试，测试模块之间的交互；约5%为端到端测试，测试贯穿全栈的关键用户流程。
技能还给出测试质量规则。测试中优先使用DAMP（Descriptive And Meaningful Phrases，描述性且有意义的表述）而非DRY，可读性优先于测试代码抽象，当能让测试自包含时，测试准备阶段的重复是可以接受的。Beyoncé规则：如果行为重要，就应当有测试验证它。测试命名应描述场景与预期结果，例如 it('should return 404 when user does not exist')，而不是 it('works')。测试隔离要求每个测试建立自己的状态，测试之间不共享可变状态，且测试应能以任意顺序运行。
使用方式
TDD循环分三步。红：在测试中定义预期行为，运行测试并确认它因正确的原因失败，测试应描述想要什么而非如何实现。绿：编写通过测试的最小实现，不添加测试未要求的功能，此阶段实现丑陋是可以接受的。重构：清理实现，提取辅助函数、改进命名、消除重复，每次重构后运行全部测试。
流程分四步。第一步先定义接口：在写测试之前定义公共接口，包括函数签名、类型定义、错误类型。第二步写第一个测试：测试最简单的正常路径，运行并观察它失败。第三步实现并迭代：让测试通过，为下一个行为写下一个测试，重复直到覆盖所有验收标准。第四步验证覆盖率：运行覆盖率报告，确保行覆盖率80%以上，确保关键路径100%覆盖，找出未测试的边界情况并补充测试。
技能还列出常见借口与反驳。例如“我以后再补测试”——以后永远不会来，未测试的代码是不可验证的代码；“TDD拖慢我”——TDD减慢打字速度，但通过减少调试时间加快交付；“这太简单不需要测试”——简单代码也会有简单缺陷，简单测试写起来成本低；“我需要先实现才知道测什么”——先定义预期行为正是重点。
验证清单
测试在实现之前编写；所有验收标准都有对应测试；覆盖率满足80%阈值；关键路径100%覆盖；测试相互隔离且与顺序无关。
限制
资料未提供该技能的具体安装命令、依赖环境、支持的语言或框架、收费与价格信息，也未提供官方文档或示例代码仓库。