BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

文章:Mock不是测试的银弹

| 作者 胡凯 关注 0 他的粉丝 发布于 2009年5月16日. 估计阅读时间: 2 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

开发者编写高质量测试的征途上可谓布满荆棘,数据库、中间件、不同的文件系统等复杂外部系统的存在,令开发者在编写、运行测 试时觉得苦恼异常。外部系统以及网络连接的不稳定性(外部系统停止响应或者网络连接超时),将有可能导致测试运行过程随机失败。另外,外部系统缓慢的响应 速度(HTTP访 问、启动服务、创建删除文件等),还可能会造成测试运行时间过长、成本过高。种种问题使开发者不断寻找一种更廉价的方式来进行测试,mock便是开发人员解决上述问题时祭出的法宝。

然而,在作者的实际项目中,虽然通过JMock确实大大降低了编写测试的难度,但是产品质量并没有如所预期的那样,随着不断添加的测试而变得愈加健 壮;虽然产品代码的单元测试覆盖率超过了80%,然而在发布前进行全面测试时,常常发现严重的功能缺陷而不得不一轮轮的修复缺陷、回归测试。

在对项目案例进行分析之后,作者指出:

真实perforce对象的行为与测试所使用的mock对象行为不一致是出现上述问题的根本原因,被模拟对象的行为与真实对象的行为必须完全一致称之为mock对象的行为依赖风险。开发者对API的了解不够、被模拟对象的行为发生变化(重构、添加新功能等修改等都可能引起被被模拟对象的行为变化)都可能导致错误假设(与真实对象行为不一致),错误假设会悄无声息的引入缺陷并留下非法测试。

继而提出了编写健壮测试的几条原则:

  • 要设计合理的等待策略来保守的使用外部系统
  • 要正确的创建和销毁资源
  • 要设计合理的过滤策略来忽略某些测试
  • 要充分利用计算资源而不是人力资源来加快测试

阅读文章全文Mock不是测试的银弹

相关阅读

[ ThoughtWorks实践集锦(1)] 我和敏捷团队的五个约定

[ ThoughtWorks实践集锦(2)] 如何在敏捷开发中做好数据迁移

[ ThoughtWorks实践集锦(3)] RichClient/RIA原则与实践(上)(下)

[ ThoughtWorks实践集锦(4)] 为什么我们要放弃Subversion

[ ThoughtWorks实践集锦(5)] “持续集成”也需要重构

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

right by Zhang Gavin

的确是这样。如果mock不能很好的模拟真实场景,那么基于这个mock所作的测试必然是不完全可信的

这不能怪Mock by kingo liang

如果Mock的时候没有能够模拟出对象的真实行为,那么这种就不能算是基于Mock的测试。

re by Lee Vincent

说了半天,原来作者就是想告诉大家——单元测试不能代替集成测试,这简直是废话。

Re: re by Jacky Li

能不能给出你的推理过程来?

Re: re by Lee Vincent

“然而出乎意料的是产品质量并没有如我们所预期的随着不断添加的测试而变得愈加健壮……然而在发布前进行全面测试时,常常发现严重的功能缺陷而不得不一轮轮的修复缺陷、回归 测试。为什么编写了大量的测试还会频繁出现这些问题呢?”
“由于测试中的stdout全由假 设得来,并不会依照环境变化,即便我们将测试跑在多种不同的环境中也没能发现问题,最终在产品环境才由客户发现并报告了这个缺陷。”
“在开发中,规避行为依赖风险最常见的方法是编写功能测试”
然后开始将如何写出能快速运行的集成测试……

Mock应用的场景只是单元测试 by Liu Min

感觉作者小题大做了。
真正的测试是很丰富的,开发人员要做单元测试、功能测试、性能测试,测试人员要做场景测试、集成测试和自动测试。
mock使用的场景仅仅是单元测试,保证代码的覆盖率和在预期环境下可以正常的工作。
单元测试不能替代功能测试和场景测试,功能测试是真实的测试,需要依赖外部资源,测试基本功能点。
场景测试比功能测试更复杂,是功能测试的复杂组合,涵盖了很多功能测试的地方,但是检查的内容更复杂一些。

Re: Mock应用的场景只是单元测试 by chan hyddd

和楼上同感,不同的测试保证不同的东西,使用MOCK也一样,看你的焦点在哪儿,而且不应就一种测试类型保证产品质量。

Re: Mock应用的场景只是单元测试 by wu darui

我觉得这个不能怪mock,日期格式随环境不一样返回值不一样,说到底还是测试没有考虑到各种因素,也就是说你mock的返回值,没有考虑到各种情况,只是测试了一条路径而已。
不过mock测试是很难写的,主要是你很难考虑到各种情况,在集成测试中也是一样的吧。
如果你在集成测试中可以反映的问题,在mock中也就可以模拟出来,这个是工作量和你能够设定的case问题。

Mock就是Mock,用错了不应该怪工具。 by 徐 毅

如题。

没什么道理 by w ym

整篇文章唯一有价值的地方就是提出了MOCK测试中容易犯的错误.但这个错误显示是人为疏忽造成的,却归咎于MOCK.....

在测试中最基本的覆盖所有条件这一步没做好,明显是编写MOCK的人经验不足,或者不细心造成的.导致这一后果的原因很可能是被mock的方法的注释写的不完整,对各种返回值没有明确说明.或者是写测试的人压根就没仔细看注释说明.

工具不能代替人思考 by wei zhang

作者所举的日期格式随环境而变的例子,是因为“没想到”,所以定义了一个不完善的mock,导致bug遗漏到用户处。可是不用Mock,或者任何其他的工具和方法能够帮助“想到”有这个需求么?答案显然是否定的。从而更加有力的证明了:决定软件质量的是人的经验和能力,而不是采用的过程和方法。Mock方法是一个工具,仅此而已。既然没有银弹已经成为公理,那么显然,Mock不是银蛋不证自明。

Re: Mock就是Mock,用错了不应该怪工具。 by zh shu

同意,从文中描述来看,作者对于怎样使用MOCK并不熟悉,路径覆盖不完全是设计case场景不到位的问题,对于作者提到的外部系统要保守使用,看起来是测试的问题,实际上是产品代码设计的问题

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

12 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT