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

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

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

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

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

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

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

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

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

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

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