你好,我是郑晔!
上一讲,我们谈到测试不好测,关键是软件设计问题。一个好的设计可以把很多实现细节从业务代码中隔离出去。
之所以要隔离出去,一个重要的原因就是这些实现细节不那么可控。比如,如果我们依赖了数据库,就需要保证这个数据库环境同时只有一个测试在用。理论上这样不是不可能,但成本会非常高。再比如,如果依赖了第三方服务,那么我们就没法控制它给我们返回预期的值。这样一来,很多出错的场景,我们可能都没法测试。
所以,在测试里,我们不能依赖于这些好不容易隔离出去的细节。否则,测试就会变得不稳定,这也是很多团队测试难做的重要原因。不依赖于这些细节,那我们的测试总需要有一个实现出现在所需组件的位置上吧?或许你已经想到答案了,没错,这就是我们这一讲要讲的 Mock 框架。
做测试,本质上就是在一个可控的环境下对被测系统/组件进行各种试探。拥有大量依赖于第三方代码,最大的问题就是不可控。
怎么把不可控变成可控?第一步自然是隔离,第二步就是用一个可控的组件代替不可控的组件。换言之,用一个假的组件代替真的组件。
这种用假组件代替真组件的做法,在测试中屡见不鲜,几乎成了标准的做法。但是,因为各种做法又有细微的差别,所以,如果你去了解这个具体做法会看到很多不同的名词,比如:Stub、Dummy、Fake、Spy、Mock 等等。实话说,你今天问我这些名词的差异,我也需要去查找相关的资料,不能给出一个立即的答复。它们之间确实存在差异,但差异几乎到了可以忽略不计的份上。
Gerard Meszaros 写过一本《xUnit Test Patterns》,他给这些名词起了一个统一的名字,形成了一个新的模式:Test Double(测试替身)。其基本结构如下图所示。
在这个图里,SUT 指的是被测系统(System Under Test),Test Double 就是与 SUT 进行交互的一个组件。有了我们之前的讲解,这个图应该不难看懂。
然而,这个名字也没有在业界得到足够广泛的传播,你更熟悉的说法应该是 Mock 对象。因为后来在这个模式广泛流行起来之前,Mock 框架先流行了起来。
Mock 框架的基本逻辑很简单,创建一个模拟对象并设置它的行为,主要就是用什么样的参数调用时,给出怎样的反馈。虽然 Mock 框架本身的逻辑很简单,但前期也经过了很长一段时间的发展,什么东西可以 Mock 以及怎样去表现 Mock,不同的 Mock 框架给出了不同的答案。
今天我们的讨论就以 Mockito 这个框架作为我们讨论的基础,这也是目前 Java 社区最常用的 Mock 框架。
要学习 Mock 框架,必须要掌握它最核心的两个点:设置模拟对象与校验对象行为。
要设置一个模拟对象,首先要创建一个模拟对象。在实战中,我们已经见识过了。
TodoItemRepository repository = mock(TodoItemRepository.class);
接下来就是设置它的行为,下面是从实战中摘取的两个例子。
when(repository.findAll()).thenReturn(of(new TodoItem("foo")));
when(repository.save(any())).then(returnsFirstArg());
一个好程序库其 API 要有很强的表达性,像前面这两段代码,即便我不解释,看语句本身也知道它做了些什么。
模拟对象的设置核心就是两点:参数是什么样的以及对应的处理是什么样的。
参数设置其实是一个参数匹配的过程,核心要回答的问题就是判断给出的实参是否满足这里设置的条件。像上面代码中,save 的写法表示任意参数都可以,我们也可以设置它是特定的值,比如像下面这样。
when(repository.findByIndex(1)).thenReturn(new TodoItem("foo"));
其实它也是一个参数匹配的过程,只不过这里做了些省略,完整的写法应该是下面这样。
when(repository.findByIndex(eq(1))).thenReturn(new TodoItem("foo"));
如果你有更复杂的参数匹配过程,甚至可以自己去实现一个匹配过程。但我强烈建议你不要这么做,因为测试应该是简单的。一般来说,相等和任意参数这两种用法在大多数情况下已经够用了。
设置完参数,接下来,就是对应的处理。能够设置相应的处理,这是体现模拟对象可控的关键。前面的例子我们看到了如何设置相应的返回值,我们也可以抛出异常,模拟异常场景。
when(repository.save(any())).thenThrow(IllegalArgumentException.class);
同设置参数类似,相应的处理也可以写得很复杂,但我同样建议你不要这么做,原因也是一样的,测试要简单。知道怎样设置返回值,怎样抛出异常,已经足够大多数情况下使用了。
模拟对象的另外一个重要行为是校验对象行为,就是知道一个方法有没有按照预期的方式调用。比如,我们可以预期 save 函数在执行过程中得到了调用。
verify(repository).save(any());
这只是校验了 save 方法得到了调用,我们还可以校验这个方法调用了多少次。
verify(repository, atLeast(3)).save(any());
同样,校验也有很多可以设置的参数,但我同样不建议你把它用得太复杂了,就连verify 本身我都建议你不要用得太多。
verify 用起来会给人一种安全感,所以,会让人有一种多用的倾向,但这是一种错觉。我在讲测试框架时说过,verify 其实是一种断言。断言意味着这是一个函数应该具备的行为,是一种行为上的约定。
一旦设置了 verify,实际上也就约束了函数的实现。但 verify 约束的对象又是底层的组件,是一种实现细节。换言之,过度使用 verify 造成的结果就是把一个函数的实现细节约定死了。
过度使用 verify,在写代码的时候,你会有一种成就感。但是,一旦涉及代码修改,整个人就不好了。因为实现细节被 verify 锁定死,一旦修改代码,这些 verify 就很容易造成测试无法通过。
测试应该测试的是接口行为,而不是内部实现。所以,verify 虽好,还是建议少用。如果有一些场景不用 verify 就没有什么可断言的了,那该用 verify 还是要用。
如果按照测试模式来说,设置 Mock 对象的行为应该算是 Stub,而校验对象行为的做法,才是 Mock。如果按照模式的说法,我们应该常用 Stub,少用 Mock。
Mock 框架的主要作用是模拟对象的行为,但作为一种软件设计思想,它却有着更大的影响。既然我们可以模拟对象行为,那本质上来说,我们也可以模拟其它东西。所以,后面也有一些基于这种模拟思想的框架,其中,目前行业中使用最为广泛的是模拟服务器。
模拟服务器顾名思义,它模拟的是服务器行为,现在在行业中广泛使用的模拟服务器主要是 HTTP 模拟服务器。HTTP 服务器的主要行为就是收到一个请求之后,给出一个应答,从行为上说,这与对象接受一系列参数,给出相应的处理如出一辙。
接下来我就以 Moco 为例,简单介绍一下模拟服务器。Moco 是我自己编写的一个开源模拟服务器程序库,曾在 2013 年获得 Oracle 的 Duke 选择奖。(在《软件设计之美》中讲到程序库的设计时,我讲过 Moco 整个设计的来龙去脉。如果你有兴趣,可以去回顾一下。)
下面是一个使用了 Moco 的测试代码。
public void should_return_expected_response() {
// 设置模拟服务器的信息
// 设置服务器访问的端口
HttpServer server = httpServer(12306);
// 访问/foo 这个 URI 时,返回 bar
server.request(by(uri("/foo"))).response("bar");
// 开始执行测试
running(server, () -> {
// 这里用了 Apache HTTP库访问模拟服务器,实际上,可以使用你的真实项目
Content content = Request.Get("http://localhost:12306/foo")
.execute()
.returnContent();
// 对结果进行断言
assertThat(content.asString(), is("bar"));
});
}
在这段代码里,我们启动了一个 HTTP 服务器,当你访问 /foo 这个 URI 时,它会给你返回一个应答 bar。这其中最关键的一行代码就是设置请求应答的那行。
server.request(by(uri("/foo"))).response("bar");
Moco 的 API 本身也有很强的表达性,通过代码本身你就能看到,这里就是设置了一个请求以及相应的应答。
Moco 的配置支持很多的 HTTP 元素,像下面这段代码,你可以同时匹配请求内容和 URI,也可以同时设置应答文本和 HTTP 的状态码。
server
.request(and(by("foo"), by(uri("/foo"))))
.response(and(with(text("bar")), status(200)));
在上面的例子里面,running 是负责模拟服务器启停的代码,里面包含的代码就是,通过自己真实的服务代码发出的真实请求。
Moco 还支持 verify,如果你想像 Mock 框架那样去校验服务器是否收到了相应的请求,就可以使用它。
RequestHit hit = requestHit();
final HttpServer server = httpServer(port(), hit);
running(server, () -> {
...
})
hit.verify(by(uri("/foo")), times(1));
虽然 Moco 支持这样的能力,但同使用 Mock 框架类似,我也建议你少用 verify。
Moco 最大的价值就是让原本不可控的第三方 HTTP 服务器,现在可以按照我们预期的方式执行。比如,在真实的集成过程,你很难要求第三方服务器给你一个错误的应答,或者一个超时的应答,但使用 Moco 你就可以让它模拟出这样的行为。
Moco 还有一个很大的价值,原本你要做集成,唯一的选项是把整个系统跑起来,基本上就到了系统集成的范畴。而现在使用 Moco,验证工作可以用集成测试的代码就可以完成。作为程序员我们很清楚,相比于系统测试,这种做法轻太多了,一旦出现问题,定位起来也容易很多。从开发效率上看,这简直是数量级的提升。
Moco 不仅仅支持模拟 HTTP 服务器,还做了进一步延伸,支持模拟 WebSocket 服务器。
HttpServer server = httpServer(12306);
webSocketServer = server.websocket("/ws");
webSocketServer.request(by("foo")).response("bar");
无论是模拟 HTTP 服务器,还是模拟 WebSocket 服务器,本质上来说,它都是模拟对象这一思想的延伸。而所有这一切的出发点都是,我们希望在测试中得到一个可控的环境。
今天我们主要讲了 Mock 框架。Mock 框架是源自 Test Double(测试替身)这种测试模式。我们希望自己有一个可控的环境对被测系统/组件进行测试,背后的思想就是用假的却可控的组件去代替真实不可控的组件。
现在 Mock 框架已经成为了测试的重要组成部分,理解一个Mock框架核心就是要理解如何设置对象行为以及如何校验对象行为。设置对象行为主要是设置相应的参数以及对应的处理,无论这个处理是给出返回值,还是抛出异常。校验对象行为是一种断言,是看对象是否按照预期方式执行。不过,我给你提了一个醒,verify 虽好,尽量少用。
最后,我们还以 Moco 为例讲到了 Mock 框架的延伸,也就是模拟服务器。Moco 主要是模拟 HTTP 服务器,其核心就是对什么样的请求,给出什么样的应答。
如果今天的内容你只能记住一件事,那请记住:使用 Mock 框架,少用 verify。
今天我们讲了 Mock 框架,你在实际工作中用到过 Mock 框架吗?它解决了你怎样的问题,或是你在使用它的过程中遇到怎样的困难,欢迎在留言区分享你的经验。