测试驱动开发（TDD） 概述 先写测试。看它失败。写最少的代码让它通过。 核心原则： 如果你没有看到测试失败，你就不知道它是否测试了正确的东西。 违反规则的字面意思就是违反规则的精神。 何时使用 始终使用： - 新功能 - Bug 修复 - 重构 - 行为变更 例外（需询问你的人类伙伴）： - 一次性原型 - 生成的代码 - 配置文件 想着"就这一次跳过 TDD"？停下来。那是在给自己找借口。 铁律 先写了代码再写测试？删掉它。从头来过。 没有例外： - 不要保留作为"参考" - 不要在写测试时"改编"它 - 不要看它 - 删除就是删除 从测试出发，重新实现。句号。 红-绿-重构 红灯 - 编写失败的测试 写一个最小的测试来展示期望行为。 <Good 名称清晰，测试真实行为，只测一件事 </Good <Bad 名称模糊，测试的是 mock 而非代码 </Bad 要求： - 一个行为 - 清晰的名称 - 使用真实代码（除非不得已才用 mock） 验证红灯 - 看它失败 必须执行。绝不跳过。 确认： - 测试失败（不是报错） - 失败信息符合预期 - 失败原因是功能缺失（不是拼写错误） 测试通过了？ 你在测试已有的行为。修改测试。 测试报错了？ 修复错误，重新运行直到它正确地失败。 绿灯 - 最少代码 写最简单的代码让测试通过。 <Good 刚好够通过测试 </Good <Bad 过…