开发者编写高质量测试的征途上可谓布满荆棘,数据库、中间件、不同的文件系统等复杂外部系统的存在,令开发者在编写、运行测 试时觉得苦恼异常。外部系统以及网络连接的不稳定性(外部系统停止响应或者网络连接超时),将有可能导致测试运行过程随机失败。另外,外部系统缓慢的响应 速度(HTTP 访 问、启动服务、创建删除文件等),还可能会造成测试运行时间过长、成本过高。种种问题使开发者不断寻找一种更廉价的方式来进行测试, mock 便是开发人员解决上述问题时祭出的法宝。
然而,在作者的实际项目中,虽然通过 JMock 确实大大降低了编写测试的难度,但是产品质量并没有如所预期的那样,随着不断添加的测试而变得愈加健 壮;虽然产品代码的单元测试覆盖率超过了 80%,然而在发布前进行全面测试时,常常发现严重的功能缺陷而不得不一轮轮的修复缺陷、回归测试。
在对项目案例进行分析之后,作者指出:
真实 perforce 对象的行为与测试所使用的 mock 对象行为不一致是出现上述问题的根本原因,被模拟对象的行为与真实对象的行为必须完全一致称之为mock 对象的行为依赖风险。开发者对 API 的了解不够、被模拟对象的行为发生变化(重构、添加新功能等修改等都可能引起被被模拟对象的行为变化)都可能导致错误假设(与真实对象行为不一致),错误假设会悄无声息的引入缺陷并留下非法测试。
继而提出了编写健壮测试的几条原则:
- 要设计合理的等待策略来保守的使用外部系统
- 要正确的创建和销毁资源
- 要设计合理的过滤策略来忽略某些测试
- 要充分利用计算资源而不是人力资源来加快测试
阅读文章全文: Mock 不是测试的银弹。
相关阅读
[ ThoughtWorks 实践集锦(1)] 我和敏捷团队的五个约定。
[ ThoughtWorks 实践集锦(2)] 如何在敏捷开发中做好数据迁移。
[ ThoughtWorks 实践集锦(3)] RichClient/RIA 原则与实践(上)、(下)。
[ ThoughtWorks 实践集锦(4)] 为什么我们要放弃Subversion 。
[ ThoughtWorks 实践集锦(5)] “持续集成”也需要重构。
评论