文章:Mock 不是测试的银弹

阅读数:1062 2009 年 5 月 15 日

话题:Java敏捷.NETRuby测试语言 & 开发文化 & 方法

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

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

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

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

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

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

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

相关阅读

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

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

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

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

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