测试驱动开发初体验

1 TDD 的价值

我们对新增代码的单元测试覆盖率有明确要求，不达标的代码是不能进主分支的。因此我们需要专门花时间写单元测试。

正常情况，我们是先写功能代码，最后补单元测试。很容易遇到如下问题：

• 已经写好的功能代码，耦合度较高，写 UT 很艰难。
• 写 UT 耗时长，易出错，基本离不开 Powermock；
• 到达一定水平后（例如 60%），UT 覆盖率很难再往上提。

如果采用 TDD 的方式，有以下优点：

• 第一次写出的功能代码，就是“易于测试”的代码，耦合度较低，UT 写起来方便快捷，较少用到 Powermock；
• 强迫自己先想清楚需求（接口应该实现什么功能），再编码实现，减少返工几率；
• UT 覆盖率很高，一次性达到要求，不需要后期花时间补单元测试；
• 为以后做重构提供可靠的保障。

2 什么是 TDD

TDD，即测试驱动开发。是敏捷开发在编码层面的一种具体实践。

2.1 澄清一些常见误解

误解 1：TDD 的重点在于写单元测试

TDD 是一种开发技术，而不是一种测试技术。

误解 2：TDD 很费时间，是一种高质量但低效的实践

如果 TDD 很费时间，实战价值不大，它就不应该是一种行之有效的敏捷方法。在 UT 覆盖率必须达标的前提下，TDD 比常规的先开发后写 UT 的方式更快。

至于开发效率，有很多影响因素，从之后的例子中可以看出，凭借对工具和方法的熟练使用，TDD 也可以很快。

误解 3：TDD 需要先把测试类写完整，才能写功能代码

这是典型的瀑布思维：先定义完整的需求，然后一次性实现。

实际的 TDD 不是这样的。先写一小部分测试代码，然后写功能代码。可以 work 之后，接着写测试代码。小步快跑。具体用法后面详细介绍。

误解 4：可以先写一个功能类，再写一个测试类；或者先写一半功能类，再写一半测试类

虽然也是小步快跑，但不是测试驱动。

2.2 TDD 的节奏

1. 写一个失败的测试；
2. 写最少的功能代码，让测试通过；
3. 重构，消除重复代码，改进设计；
4. 再写一个失败的测试，循环往复。

理论上，每一次小型增量迭代结束后，都得到一个可以 work 的，覆盖率 100% 的系统。

2.3 TDD 的原则

1. 没有失败的测试就不能写代码；
2. 只写恰好让测试通过的代码（在不超过1分钟的时间内，让一个失败的测试通过）。

3 TDD 实战体验：FizzBuzz

下面，通过一个实际的例子，来感受一下 TDD 的运用方式。

3.1 FizzBuzz 开发需求

题目描述

写一个程序，打印出从1到100的数字，将其中3的倍数替换成“Fizz”，5的倍数替换成“Buzz”。既能被3整除、又能被5整除的数则替换成“FizzBuzz”。

样例输出：

验收要求

• 10min 内完成功能（有一些同学在长期练习后可以做到 2 分钟内完成）
• UT 覆盖率 100%
• 代码尽量符合规范，没有重复代码

乍一看，这个需求很简单。但是考虑到 UT 和代码质量，就变得很难。

3.2 实操

我们可以打开计时器，正儿八经地做一下这道题目。看能做到什么程度，过程中有没有磕磕碰碰。

（此处省略一万字）

3.3 课代表示范

[evp_embed_video url="http://jiuyeban-public.jikexueyuan.com/attachment/2019/0514/folder/rD3pPDuG7xF3Ie07fcTXQvFh8HaoFNv5ID0qcSBA.mov"]