# TDD (test drive development) 测试驱动开发

# 测试驱动开发的口号：

测试先行

# 测试驱动开发的目标：

保证代码的简洁可用

# TDD 的规则

在 TDD 的过程中，需要遵循两条简单的规则：

仅在自动测试失败时才编写新代码。
消除重复设计（去除不必要的依赖关系），优化设计结构（逐渐使代码一般化）。

第一条规则的言下之意是每次只编写刚刚好使测试通过的代码，并且只在测试运行失败的时候才编写新的代码，因为每次增加的代码少，即使有问题定位起来也非常快，确保我们可以遵循小步快跑的节奏；第二条规则就是让小步快跑更加踏实，在自动化测试的支撑下，通过重构环节消除代码的坏味道来避免代码日渐腐烂，为接下来编码打造一个舒适的环境。
关注点分离是这两条规则隐含的另一个非常重要的原则。其表达的含义指在编码阶段先达到代码 “可用” 的目标，在重构阶段再追求 “简洁” 目标，每次只关注一件事

# 采用 TDD 的动机

控制编程过程中的忧虑感。

有一个有趣的想象，当我感觉压力越大，自身就越不想去做足够多的测试。当知道自己做的测试不够时，就会增加自身的压力，因为我担心自己写的代码有 BUG，对自己编写的代码不够自信，这是一种心态上的变化。此时测试是开发人员的试金石，可以将对压力的恐惧变为平日的琐事，采用自动化测试，就有机会选择恐惧的程度。

把控编程过程中的反馈与决策之间的差距。

如果我做了一周的规划，并且量化成一个个可操作的任务写到 to-do list，然后使用测试驱动编码，把完成的任务像这样划掉，那么我的工作目标将变得非常清晰，因为我明确工期，明确待办事项，明确难点，可以在持续细微的反馈中有意识地做一些适当的调整，比如添加新的任务，删除冗余的测试；还有一点更加让人振奋，我可以知道我大概什么时候可以完工。项目经理对软件开发进度可以更精确的把握。

标注：本文摘抄自：https://juejin.cn/post/6844903780970921991
感兴趣可自行进行查看