AspectJ 和模仿对象的测试灵活性：用“test-only”行为增强单元测试

核心提示： 如果客户机返回了预期的结果，那么测试就将通过，AspectJ 和模仿对象的测试灵活性：用“test-only”行为增强单元测试(5)，虽然这个测试非常简单，您还是可以轻易地想象同样的过程会如何应用到更复杂的客户机上，有了功能测试，进行依赖数据的测试就更有意义，比如根据对 EJB 组件的调用生成输

如果客户机返回了预期的结果，那么测试就将通过。虽然这个测试非常简单，您还是可以轻易地想象同样的过程会如何应用到更复杂的客户机上，比如根据对 EJB 组件的调用生成输出的 servlet。

如果您已经安装了样本应用程序，那么请试着用示例目录中的命令 ant basic 运行这个测试若干次。

依赖数据的测试的问题

在运行了几次上述测试后，您就会注意到结果是不一致的：有时候测试会通过，有时候不会通过。这种不一致性归咎于 EJB 组件的实现 ― 而不是客户机的实现。示例中的 EJB 组件模拟了一个不确定的系统状态。测试数据中的不一致性显示出了在实现简单的、以数据为中心的测试时将出现的实际问题。另一个比较大的问题就是容易重复测试工作。我们将着手解决这里的两个问题。

数据管理

克服数据中不确定性简单的方法就是管理数据的状态。如果我们能够设法在运行单元测试之前保证系统中有 55 条客户记录，那么我们就可以确信 getCustomers() 测试中的任何失败情况都可以表明代码中有缺陷，而不是数据问题。但是管理数据状态也会带来它自己的一些问题。您必须在运行每个测试之前确保系统对于特定测试处于正确的状态。如果您缺乏警惕，那么其中一个测试的结果就可能以某种方式改变系统的状态，而这种方式将使下一个测试失败。

为了应付这种负担，您可以使用共享设置类或批输入进程。但这两种方法都意味着要对基础结构作出很多投入。如果应用程序在某种类型的存储设备上持久化它的状态，您可能还会碰到更多问题。向存储系统添加数据可能很复杂，而且频繁的插入和删除可能使测试的执行非常缓慢。

高级测试

本文将集中讨论单元测试，然而集成测试或功能测试对快速的开发和较高的质量同样重要。实际上，这两种类型的测试是互补的。高级测试将验证系统的端对端完整性，而低级单元测试将验证单独组件。两种测试在不同情况下都是有用的。举例来说，功能测试可能通过了，但单元测试却找出了一个只在很少情况下才会出现的错误。反之亦然：单元测试可能通过了，而功能测试却显示各单独组件没有被正确地连在一起。有了功能测试，进行依赖数据的测试就更有意义，因为它的目标是验证系统的聚集行为。