Testing on the Toilet:不要滥用Mock

本文选自 Google 的“Testing on the Toilet (TotT) ”章节。

在编写测试代码的时候,单纯的使用Mock来规避代码依赖性,执行测试是很容易的:

不过,如果我们不用Mock来实现测试代码的话,可能测试代码看起来更简单,更有效:

上述代码就是滥用Mock的例子,滥用Mock类会带来不少问题:

1. 测试代码可读性很差

放弃直接使用你的被测产品代码逻辑(例如,直接把测试输入传递给被测方法,然后检查输出),你需要编写额外的代码以告诉Mock类如何行为。这些额外的代码实际上反映的是想如何进行测试,这些代码的可读性通常很差,尤其是你不了解产品代码的内在实现的情况下。

2. 测试代码可维护性很差

当你告诉Mock类如何行为时,你就会把产品代码中的一些实现也带入到测试代码中来。而一旦产品代码的实现发生了改变,你可能就需要对测试代码进行更新以适应产品代码的变更。而我们知道,典型的测试代码应该与被测试产品代码松耦合,测试代码应该着眼于被测代码的外部接口(而不是他们的实现)。

3. 测试代码对被测产品质量的保证水平也会降低(言外之意,测试代码的执行失败不一定代表着被测试产品的质量有问题)

当你在测试代码中加入了过多的实现细节,那么只有被测试代码严格符合你在Mock中描述的所有行为时,测试结果才正确。而这一点很难保证,尤其是如果被测试代码频繁变更的情况下,因为被测试代码和测试代码做到实时同步是很困难的。

你在滥用Mock的一些迹象:你试图在一个测试中Mock过多(超过一两个)的类,或者你的Mock方法描述了过多(超过一两个)方法的行为。亦或者,如果你在读测试代码的时候,你发现需要了解被测试产品代码的实现才能读懂,那么,小心,你可能在滥用Mock。

有时你很难在测试中实现真正的独立性(例如,可能使测试很慢,或者测试依赖于网络等硬件),但是在使用Mock之外你仍然有很多更好选择,例如使用独立的本地服务(例如,一个启动在本地的模拟信用卡服务的应用)或者一个产品代码的伪实现(例如,一个驻留在内存中的信用卡服务程序)。

译注:这是一个老生常谈的话题,实际就是该用Stub用Stub,该用Mock用Mock。

 

英文原文: google testing blog, 翻译: 柴阿峰

译文链接: http://blog.jobbole.com/41342/

【非特殊说明,转载必须在正文中标注并保留原文链接、译文链接和译者等信息,谢谢合作!】

收藏 评论

关于作者:柴阿峰

柴阿峰:比搞技术的相声说的好,比说相声的测试懂得多。反技术教条主义,反测试无用论。专注于开源测试技术、半自动化测试、测试架构、测试方法等的研究。(新浪微博:@柴阿峰 ,邮箱:chaiafeng#163.com) 个人主页 · 我的文章

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部