因收到Google相关通知,网站将会择期关闭。相关通知内容

11 集成测试:单元测试可以解决所有问题吗?

你好,我是郑晔!

前面我们花了大量的篇幅在讲单元测试。单元测试是所有测试类型中,运行速度最快,整体覆盖面可以达到最大的测试。因为单元测试的存在,我们甚至可以把测试覆盖率拉高到 100%。测试覆盖率都已经 100%了,是不是我们用单元测试就可以解决所有的问题了?

正如我们在上一讲强调的那样,100%的测试覆盖率并不代表代码没有问题。同样,即便是 100% 的单元测试也不能解决所有的问题。有一个重要的原因在于,我们在编写每个单元时都会假设这些单元彼此之间能够很好地协同,但这个假设是不是一定成立呢?答案是不一定。

让一个个单元正常运行,我们靠的不是美好的预期,而是单元测试。同样,各个单元能够很好地协同,我们也不能靠预期,而是要靠集成测试。这一讲,我们就来讨论一下集成测试。

代码的集成

在具体讨论集成测试之前,我们澄清一下概念。集成测试到底测的是什么?答案很显然是集成。问题是,集成要集成什么呢?一种是代码之间的集成,一种是代码与外部组件的集成。说白了,集成测试就是把不同的组件组合到一起,看看它们是不是能够很好地配合到一起。

我们先来看代码的集成。代码之间的集成,主要看我们编写的各个单元能否很好地彼此协作。既然集成测试是为了测试单元之间的配合,那是不是只要有单元之间的协作,我们就要为它们编写一个集成测试呢?比如按照常规的架构分层,一个 REST 服务会有一个 Resource(或者叫 Controller),一个 Service,一个 Repository,那是不是要 Service 和 Repository 的集成要写一个集成测试,Resource 和 Service 的集成测一次,Resource、Service 和 Repository 的集成再测一次呢?

如果我们按照前面讨论的方式来编写了单元测试,其实,这就意味着我们每个组件都已经经过了测试。所以,集成测试的重点就不再是组件之间两两协同进行测试了。一般来说,在实践中,我们可以选择的测试方式是,选择一条任务执行的路径,把路径上用到的组件集成到一起进行测试。比如在前面提到的那种情况中,我们只要把 Resource、Service 和 Repository 都组装到一起就可以了。

如果所有的代码都是我们自己编写,那么我们就编写一个个的单元,然后组装到一起进行测试,这个很好理解。但是,现在很多人都在使用框架,比如我们在实战中处理命令行时使用了 Picocli 这个框架,所有的命令解析的过程都是由这个框架完成;再比如,很多人在开发后端服务时,使用了 Spring Boot,一些路由匹配,甚至参数检查都是由框架完成的。那么我们在集成测试中,要不要把这个部分集成进来呢?

我对此的答案是,取决于你是否能够把这个框架集成进来,如果能,最好是做一个完整的集成测试。在实战中,我们已经展示过如何去集成 Picocli,因为这个框架本身比较简单,很容易找到这个框架的外部入口,我们就把它集成起来,做了一个完整的测试。

有的框架可能就没有那么简单了,就像当年 Java EE 盛行时,我们编写的代码需要部署到一个 Java EE 的容器里面才能运行。在这种情况下,如果强行把 Java EE 容器也加到集成测试里,对于大多数人来说,这是非常有难度的一件事情。换言之,像这种有单独运行时的框架,做整体的集成难度很大,我们只能退而求其次,做大部分的代码集成。

现在的很多框架替我们做了很多的事情,有些甚至是业务验收标准上的事情,比如,Spring Boot 会替我们做参数检查,利用好 Spring Boot 给我们提供的机制,我们甚至不用写什么代码,只要给字段加上一些 Annotation 就够了。这些 Annotation 加的是否正确,我们其实是需要验证的,因为它是业务验收标准的一部分。

所以我希望尽可能地去集成,如果我们能够把整个框架集成起来,这些东西也就可以验证了。从代码上来看,这种测试只是针对一个单元在测试,在某种程度上说,这种集成测试其实是一种单元测试,只不过,它必须把系统集成起来才行,所以,它兼具单元测试和集成测试的特点。

小小预告一下,Spring Boot 在测试上的支持是真的很不错,让我们可以很容易地在测试里对框架处理过程进行集成,在后面的课程里你会看到如何使用 Spring Boot 提供的测试基础设施进行测试。

你也看到了,我们希望尽可能地把框架集成进来,但市面上的各种框架层出不穷,不是所有的框架都提供了对测试很好地支持。所以,一个框架设计得好坏与否,对测试的支持程度也是一个很重要的衡量标准,这能很好地体现出框架设计者的品味。

能够方便测试的框架,通常来说都是很轻量级的,这样的框架对开发非常友好,我们能够在一个普通的 IDE 里很方便地进行调试,对于定位问题也是极其友好的。而各种有运行时需要部署的框架,相对来说,就是重量级的框架,对于开发非常不友好。如果你用过一些 IDE 支持的远程调试功能,你会发现这些功能跟本地调试相比,便捷程度完全不在一个档次上。

好消息是,我们还是能看到一些框架的进步,即便重如 Java EE 这样的框架,现在也有了嵌入式容器的概念。今天,我们之所以能够很方便地使用 Spring Boot 这样的框架,嵌入式容器给我们提供了非常好的基础。

集成外部组件

说完了代码的集成,我们再来看看与外部组件的集成。

在真实世界的开发中,我们经常会遇到与外部组件打交道的情形,最简单是数据要写到数据库里,还有发消息可能会用到消息队列,甚至还可能会涉及与第三方系统的集成。

理想情况下,我们当然希望把所有相关的组件都集成到一起,但是,一旦牵扯到外部组件,测试的难度立刻就增大了。比如在测试中添加了 Todo 项,如果我的断言写的是先判断数据库里 Todo 项表里有唯一的一条记录,执行之前,你因为其它操作在数据库里插入了数据,这个断言就失败了。即便没有人操作,这个测试执行第一次成功了,再执行一次,可能就失败了,因为第二次执行测试又插入了一条数据。

所以,与外部组件集成,难点就在于外部组件的状态如何控制。

如果能够控制外部组件的状态,在系统里集成它是没有问题的。比如拿数据库集成来说,通常的做法是一方面,我们会建立单独的数据库,保证不与其他部分冲突。比如在 MySQL 里面,我们会建立一个测试用的数据库。

CREATE DATABASE todo_test;

另一方面,我们要保证它在每个测试之后,都能够恢复到之前的状态。一种做法就是使用数据库的回滚技术,每个测试完成之后就回滚掉,保证数据的干净。后面讲到 Spring Boot 测试的时候,我们会看到具体的做法。

相对来说,数据库在测试方面的实践已经算是比较成熟了。这也让我们可以去验证 Repository,也就是数据访问层的代码实现。不管使用什么样的框架,写了 SQL 之后,我们都需要验证其正确性。只不过,很多人的选择是把整个系统跑起来,人工去验证 SQL 的正确性,这种做法一方面有些小题大做了,另一方面还是不够自动化。

有了数据库在测试上的实践,我们就可以用自动化测试的方式进行测试了。其实,从某种意义上说,这也是一种单元测试,因为它的代码只涉及到了一个单元,只不过它需要集成数据库,所以,它还是集成测试

还有一些外部组件在这方面的支持相对来说,就不那么令人满意了。比如第三方系统。即便是服务做得很完善的第三方系统,也很少有专门为测试提供支持的。

遇到这种情况,我们就要分析一下,看看有没有什么替代方案。很多第三方系统对外提供服务的方式都是 REST API,对于这种情况,我们就可以用通用的模拟服务器来代替。模拟服务器的价值就在于能够替代这样的第三方服务。

在这种情况下,我们该怎么做呢?我们需要按照我们的使用场景去访问第三方服务,把整个访问的报文记录下来,作为设置模拟服务器的参考依据。我介绍过的 Moco 甚至提供了代理(proxy)功能,你可以让你的服务去连接 Moco,然后,用 Moco 连接第三方的服务,只要查看 Console 输出,所有的报文就清清楚楚地展现在你面前了。

如果外部组件没有现成的替代方案怎么办?有两个角度看待这个问题。一个角度是,这也许是一个做新项目的机会,我在《软件设计之美》中讲过 Moco 的开发过程,其起始点就是一个没有很好解决的问题。

另一角度,估计是大多数人的选择,那就是既然这里测不了,我可以选择在集成测试里使用模拟对象,而不是真实的对象。在这样的情况下,我们的系统在测试方面其实有一个漏洞没有被测试很好地覆盖。也就是说,我们要把这个漏洞留到更上一层的测试。如果这个漏洞是一个简单的逻辑(比如一个消息队列发消息的接口),这样还好。如果里面有逻辑,我们必须把它作为一个重点的风险提示加以重视。不过,好在这种情况并不是很多,毕竟像 SQL 这种有复杂逻辑的东西,我们已经有了解决方案。

总结时刻

今天我们讲了集成测试,相对于单元测试只关注单元行为,集成测试关注的多个组件协同工作的表现。今天我们讨论了两类典型的集成问题,一种是代码之间的集成,一种是代码与外部组件的集成。

对代码之间的集成来说,一方面要考虑我们自己编写的各个单元如何协作;另一方面,在使用各种框架的情况下,要考虑与框架的集成。如果我们有了单元测试,这种集成主要是关心链路的通畅,所以一般来说我们只要沿着一条执行路径,把相关的代码组装到一起进行测试就可以了。

如果涉及框架,最好是能够把框架集成一起做了,设计得比较好的框架是对于测试的支持比较好的(比如像 Spring Boot),可以让我们很方便地进行测试。

对于外部组件的集成而言,难点在于如何控制外部组件的状态。数据库在这方面相对已经有比较成熟的解决方案:使用单独的数据库,以及在测试结束之后进行回滚。

但大部分系统没有这么好的解决方案,尤其是第三方的服务。这时候,我们就要看有没有合适的替代方案。对于大多数 REST API,我们可以采用模拟服务器对服务进行模拟。

通过今天的讨论你会发现,严格地说,有些代码由于基础设施的问题是不容易在自动化场景覆盖的,这也是我们为什么要强调与框架结合的代码一定要薄,让这种代码的影响尽可能少。这也是在减少用上层测试覆盖的工作量。

到这里,大部分的场景我们都已经可以用自动化测试进行覆盖了,我们对自己的系统已经有了更完整的理解。其实,测试的种类还有更多,比如系统测试,把整个系统集成起来测试;验收测试,交由业务人员或测试人员进行测试。但这些测试对于很多团队来说,已经到了测试人员的工作范畴了。作为程序员,我们能够把单元测试和集成测试做好,整个软件的质量已经是初步合格了。

如果今天的内容你只能记住一件事,那请记住:想办法将不同组件集成起来进行测试。

思考题

今天我们讲了集成测试,你也看到了集成测试难点就在于如何集成。在实际工作中,你遇到过哪些难以在测试中集成的情况吗?欢迎在留言区分享你的经验。