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