01、前言

很早之前，曾在网络上见到过 TDD 这 3 个大写的英文字母，它是 Test Driven Development 这三个单词的缩写，也就是“测试驱动开发”的意思——听起来很不错的一种理念。

其理念主要是确保两件事：

• 确保所有的需求都能被照顾到。
• 在代码不断增加和重构的过程中，可以检查所有的功能是否正确。

但后来很长一段时间里，都没再听过 TDD 的消息。有人说，TDD 已经死了，给出的意见如下：

1）通常来说，开发人员不应该在没有失败的测试用例下编写代码——这似乎是合理的，但是它可能导致过度测试。例如，为了保证一行生产代码的正确性，你不由得写了 4 行测试代码，这意味着一旦这一行生产代码需要修改，你也得修改那 4 行测试代码。

2）为了遵循 TDD 而写的代码，容易进入一个误区：代码是为了满足测试用的，而忽略了实际需求。

02、TDD 到底是什么？

不管 TDD 到底死了没有，先让我们来回顾一下 TDD 到底是什么。

TDD 的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完全部功能的开发。

TDD 的基本过程可以拆解为以下 6 个步骤：

1） 分析需求，把需求拆分为具体的任务。

2） 从任务列表中取出一个任务，并对其编写测试用例。

3） 由于没有实际的功能代码，测试代码不大可能会通过（红）。

4） 编写对应的功能代码，尽快让测试代码通过（绿）。

5） 对代码进行重构，并保证测试通过（重构）。

6） 重复以上步骤。

可以用下图来表示上述过程。

那接下来，王二需要快速让测试通过，Ticket.sale() 方法修改后的结果如下：

public class Ticket {

public BigDecimal sale(int count) {
if (count == 1) {
return new BigDecimal(“99”);
}
return BigDecimal.ZERO;
}

}

再运行一下测试用例，结果如下图所示，绿色表示测试通过了：预期结果是 99，实际结果是 99。

有两个测试用例没有通过，那么王二需要继续修改功能代码，调整如下：

public class Ticket {
private final static int PRICE = 99;

public BigDecimal sale(int count) {
if (count < 0) {
throw new IllegalArgumentException(“销量不能为负数”);
}

if (count == 0) {
return BigDecimal.ZERO;
}

if (count == 1) {
return new BigDecimal(PRICE);
}

return new BigDecimal(PRICE * count);
}

}

再运行一下测试用例，发现都通过了。又到了重构的时候了，销量为零、或者大于等于一的时候，代码可以合并，于是重构结果如下：

public class Ticket {
private final static int PRICE = 99;

public BigDecimal sale(int count) {
if (count < 0) {
throw new IllegalArgumentException(“销量不能为负数”);
}

return new BigDecimal(PRICE * count);
}

}

重构结束后，再运行测试用例，确保重构后的代码依然可用。

04、最后

从上面的实践过程可以得出如下结论：

TDD 想要做的就是让我们对自己的代码充满信心，因为我们可以通过测试代码来判断这段代码是否正确无误。

也就是说，TDD 流程比较关键的一环在于如何写出有效的测试代码，这里有 4 个原则可以参考：

1）测试过程应该尽量模拟正常使用的过程。

2）应该尽量做到分支覆盖。

3）测试数据应该尽量包括真实数据，以及边界数据。

4）测试语句和测试数据应该尽量简单，容易理解。

注意，这 4 个原则不仅适用于 TDD，同样适用于任何流程下的单元测试。