测试：开发人员理想与现实的大 PK

PDC 大会上进行了关于“单元测试的未来”的小组讨论，大部分的谈话内容聚焦于 Mock 测试，人们对于 Mock 框架（Mock frameworks）的过度使用取得了普遍共识。

共识如下：通常，实现所有必要的接口非常无聊，而且消耗时间。为了更方便，人们选择了 Mock 框架。但这遮盖了更本质的问题：API 被设计得过于复杂。

关于“开发人员测试”与其他人员的测试之间的区别，有一个热门的话题。一直以来的讨论中，人们都认为开发人员只需要做单元测试，而需求测试、验收测试、集成测试，以及所有其他形式的测试都是其他人的工作。

这里强调了在单元测试社区中存在的一个普遍误解。具体来说，就是假设所有开发人员都配备了 QA 团队，以处理所有其他类型的测试。不幸的是，即使是拥有数百万资金的公司也往往根本没有 QA 资源，所有的测试都留给了开发人员和最终用户。

开发人员无法进行更多类型测试的主要原因是速度。 单元测试已经太慢了，因此没有更多时间去进行那些更慢的测试了，比如包括网络通信的测试。 遗憾的是，并没有人考虑其他变通之策。

举个例子，单元测试框架其实可以更加智能，它们可以使用代码覆盖率的结果，只对发生变化的代码进行二次测试。一个类的变化，不应该触发重新运行所有的测试集合。所谓“单元测试”意味着你只需测试一个小的子集即可。

另外一种没有被提及的改进是利用分布式编程。代码和测试可以被快速上传到各个服务器并且得到执行。通过引入持续集成，我们已经拥有了所有需要的技术。

早些的讨论普遍觉得数据库方面被忽视了，大部分的数据库开发人员很少或几乎没有单元测试的概念，也缺乏相关支持工具。更可怕的是，他们甚至都没有被邀请来参加讨论。遗憾的是这就是目前的现状。讨论中也没有提供方法改善这些现实问题。

从好的方面看，已经有一些人在讨论使用建模工具来让单元测试更加简单。他们提供了很多可选的办法，例如从定义契约级别开始。这些契约可以被代码生成器用来编写实际的测试代码。显然，这并非一个 100% 完美的解决方案，但它能够减少经常遇到的困难。

另一个被看好的办法是采用 delta 状态管理。设想测试“取钱”这个功能，很多人会假设被测试帐户最开始有 100 美元，经过交易后，剩下 80 美元。这个方法就是首先查询一下账号余额，然后再看是否减少了 20 美元。这样一来，就不必在每次运行测试时都重新设置测试环境了。

查看英文原文： Testing: What Developers Are Expected To Do Versus What They Actually Do

译者简介：王速瑜，毕业于华中科技大学，就职于腾讯科技（深圳）有限公司，担任R&D 研发总监，现负责腾讯敏捷产品开发技术的实践和推广及研发基础平台的管理工作。熟悉Java、Microsoft.net、Lamp 等技术。对互联网大规模应用技术、高性能网格技术，SOA 等有非常浓厚的兴趣和深入的实践，喜欢Open Source，关注Ruby、Erlang 的发展并积极实践，愿意为技术而挥洒激情，为让更多人了解精彩技术而付出努力！志愿参与InfoQ 中文站内容建设，请邮件至 editors@cn.infoq.com 。也欢迎大家到 InfoQ 中文站用户讨论组参与我们的线上讨论。