TDD 初探

[tiantingrui]

TDD 初探 & 找零钱

什么是TDD

Test Driven Development

简单来讲，TDD 只是通过单元测试来推动代码的编写，然后通过重构来优化程序的内部结构。

这很容易被理解成只需要先写单元测试就可以驱动出高质量的代码。

推荐书籍：Kent Beck 的著作《测试驱动开发》

这本书的观点让我感触很深

测试驱动开发不是一种测试技术。它是一种分析技术、设计技术，更是一种组织所有开发活动的技术

分析技术： 体现在对问题域的分析，当问题还没有被分解成一个个可操作的任务时，分析技术就派上用场，例如需求分析、任务拆分和任务规划等

设计技术： 测试驱动代码的设计和功能的实现，然后驱动代码的再设计和重构，在持续细微的反馈中改善代码。

组织所有开发活动的技术： TDD 很好地组织了测试、开发和重构活动，但又不仅限于此，比如实施 TDD 的前置活动包括需求分析、任务拆分和规划活动，这使得 TDD 具有非常好的扩展性。

TDD 目的

对于如何保证“代码简洁可用”可以使用分而治之的方法，先达到“可用”目标，再追求“简洁”目标。

1. 可用
2. 代码简洁

TDD 的规则

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

采用TDD的最大优点（对个人而言）把控编程过程中的反馈与决策之间的差距，换句话说就是更加精确的知道开发进度。

TDD 的整体流程

1. 想一下我要做什么，想想如何测试它，然后写一个小测试。思考所需的类、接口、输入和输出。
2. 编写足够的代码使测试失败（明确失败总比模模糊糊的感觉要好）。
3. 编写刚刚好使测试通过的代码（保证之前编写的测试也需要通过）。
4. 运行并观察所有测试。如果没有通过，则现在解决它，错误只会落在新加入的代码中。
5. 如果有任何重复的逻辑或无法解释的代码，重构可以消除重复并提高表达能力（减少耦合，增加内聚力）。
6. 再次运行测试验证重构是否引入新的错误。如果没有通过，很可能是在重构时犯了一些错误，需要立即修复并重新运行，直到所有测试通过。
7. 重复上述步骤，直到找不到更多驱动编写新代码的测试。

TDD的难点

1. 缺乏软件质量意识
2. 缺乏一定程度的程序设计能力，很难设计出高内聚低耦合、意图清晰的结构和代码。
3. 缺乏分析需求并进行任务分解和规划的能力，很容易在还没开始 TDD 的时候就被打乱了节奏。
4. 缺乏合适的测试环境和测试规范。
5. 测试优先的习惯难以养成。
6. 重构手法不熟练。