Test-Driven Development（TDD）是一套用于指导代码编写方式的实践技能，围绕 Red → Green → Refactor 循环展开，适用于所有代码变更。其目标是在实现代码之前先通过测试明确需求，从而保证代码行为符合预期并可持续改进。
TDD 循环
该技能将开发过程划分为三个阶段：
- RED：编写会失败的测试。
- GREEN：编写刚好能让测试通过的最小代码。
- REFACTOR：改进代码质量。
对每一个需求重复上述过程。
适用与不适用场景
资料明确给出了应当使用和可以跳过 TDD 的情形。
始终使用 TDD 的场景：
- 新函数／新方法
- 新功能
- Bug 修复（先复现问题）
- 重构既有代码
- API 变更
可以跳过 TDD 的场景：
- UI 样式微调
- 配置变更
- 文档更新
操作流程
1. 先写会失败的测试
以测试为起点，例如：
# Start with test
test "calculates total with tax" do
result = Calculator.calculate_total([100, 200])
assert Money.equal?(result, Money.new(:USD, 324))
end
# Run test - should FAIL
mix test
2. 实现最小代码
只写足以让测试通过的代码：
# Just enough to pass
def calculate_total(prices) do
prices |> Enum.sum() |> Kernel.*(1.08) |> Money.new(:USD)
end
3. 重构
提取常量、改进命名等。
按技术栈划分的测试模式
资料给出了两类技术栈的测试文件约定。
后端（Elixir）：
- 文件：test/path/module_test.exs
- 模式：apps/api/test/your_app/task/task_test.exs
前端（TypeScript）：
- 文件：ComponentName.test.tsx
- 模式：mobile/libraries/atorasu/atoms/Button/Button.test.tsx
关键规则
- 测试必须先失败（验证测试本身有效）
- 每个需求一个测试
- 测试行为，而非实现
- 提交前运行完整测试套件
- 绝不跳过失败测试
常见陷阱
- 先写实现、后写测试
- 测试在没有实现的情况下也能通过（假阳性）
- 测试实现细节而非行为
- 未先运行测试确认其失败
验证方式
后端与前端分别使用以下命令进行验证：
# Backend
mix test path/to/test.exs
# Frontend
yarn test path/to/test.tsx
限制与未提供信息
资料未提供该技能的安装方式、依赖要求、支持的完整技术栈清单、与具体框架的集成配置，以及收费或价格相关信息，这些内容暂未提供。