tdd 测试驱动开发

最新推荐文章于 2024-08-13 20:33:28 发布

开平碉楼

最新推荐文章于 2024-08-13 20:33:28 发布

阅读量298

点赞数

1 测试驱动开发模式

1.1 重新定义“测试”

这是一张影响图：

普通箭头表示当第一个节点增长时，第二个节点也会做相应的增长。
带圆圈的箭头表示当第一个节点增长时，第二个节点也会做相应的减少。

当压力越大时，所做的测试就会越少。测试越少，犯的错就会越多，就会感到更大的压力。这是一个会造成情境越来越糟的循环。

我们用事先编写的测试来驱动开发，因为测试先于开发，所以我们在感到压力时，就运行这些测试，它们会马上给我们一种系统良好的感觉，而且会减少开发出错的次数，进而减少我们的压力，从而跳出上面的循环。

1.2 测试的要求

让测试尽可能快地运行。
尽量在小范围内进行。
测试之间互不干扰，这意味着所有的测试都是不依赖于顺序的。这样就不会因为测试顺序的不同而出现的许多古怪问题。这对开发人员提出了更高的要求，因为必须把问题分解为彼此正交的小问题，这样做的好处是，每个测试会变得更加简单而且可以快速运行，对象也会变成漂亮的“高内聚、低耦合”的类对象。

1.3 测试列表

写一张包含所有要编写的测试清单，可以记录在一张纸上。这张表记录的就是我们要去实现的测试。

1.4 测试优先

在编写要被测试的代码之前也编写测试代码。

1.5 断言优先

从测试完成时能够通过的断言（形如 assertEquals()）开始编写测试代码。

1.6 测试数据

使用让人容易理解的数据，记住，你写的代码以后会有人阅读、有人维护的！

在以下的情况下，使用真实世界中的数据很有效：

将目前系统的输出与以前系统的数据进行比对时。
对旧系统进行重构而期望在完成时得到完全相同的结果时。

1.7 可阅读的数据

让测试包含预期和实际的结果，努力让它们容易理解，因为还要让其他人阅读的，所以要留下尽可能多的线索。

1.8 学习测试

使用一个公开的 API 接口或者包时，可以编写一个测试来验证这个 API 工作是否符合我们的期望。这样做有两点好处：
* 可以让我们更好地理解它。
* 如果测试无法运行，可能是使用的问题，也可能是 API 本身的问题，测试会让问题更快地暴露出来。

1.9 休息

当你感觉到累的时候，休息一下。适当的放松会让大脑的思维得到解放。

2 测试代码的编码模式

2.1 子测试

保持不可运行-》可运行-》重构的节奏对可持续的成功非常重要。付出额外的努力来保持这种节奏是值得的。当之前的测试代码突然要求几处变化时，可能的原因是我们之前所写的测试代码太大了，这就需要重构把这些测试代码，尝试把它变成几个子测试代码咯。

2.2 模拟对象

如果一个测试依赖于昂贵而且复制的资源对象，那么就创建一个这些资源的模拟对象。典型的例子是数据库，建立它很耗时间，而且它也是开发过程中错误产生的温床。

解决办法是在大多数时间里不使用真正的数据库，而是写一个像数据库一样的对象，或者采用一个第三方开源的数据库模拟 API，让它仅仅驻留在内存中。这样做，不仅带来了高效的性能，而且还很可靠，可读性也很好。

如果担心模拟对象与现实对象的行为不一致，那么可以使用对实际对象适用的一系列测试来测试模拟对象，从而减少这种风险。

2.3 清理测试死角

抛出一个异常对象来测试代码中处理错误的逻辑。因为我们的安全假设是，没有被测试过的代码是不会正常工作的，处理错误的逻辑也是代码的一部分，所以我们也要进行测试。

假设要测试当文件系统满了以后，系统会发生什么。可以花费很多时间创建许多大文件来填满整个文件系统，这种方法费时费力。另一种方法是采用伪实现，即抛出一个异常：

public class FullFile extends File {
    public FullFile(String path){
        super(path);
    }
    public boolean createNewFile() throws IOException {
        throw new IOException();
    }
}
 
 1
2
3
4
5
6
7
8