Java测试工具JUnit_4

这会很好地工作，但它需要我们手动地将所有测试添加到一个套件中。早期的JUnit采用者告诉我们这样是愚蠢的。只要你编写一个新的测试案例，你就必须记着要将其添加到一个static的suit()方法中，否则其将不会运行。我们添加了一个TestSuit的便捷构造方法，该构造方法将测试案例类作为一个参数。其意图是提取（extract）测试方法，并创建一个包含这些测试方法的套件。测试方法必须遵循的简单的约定是，以前缀“test”开头且不带参数。便捷构造方法就使用该约定，通过使用反射发现测试方法来构造测试对象。使用该构造方法，以上代码将会简化为：

public static Test suite() {  return new TestSuite(MoneyTest.class);  }

　　当你只是想运行测试案例的一个子集时，则最初的方式将依然有用。
3.6 总结

　　现在我们位于JUnit走马观花的最后。通过模式的角度来阐述JUnit的设计，可如下图所示。

图6 JUnit模式总结

　　注意TestCase作为框架抽象的中心，其是如何与四个模式进行相关的。成熟的对象设计的描述展示了这种相同的“模式密度”。设计的中心是一个丰富的关系集合，这些关系与所支持的参与者（player）相互关联。

　　这是另外一种看待JUnit中所有模式的方式。在这个情节图板（storyboard）上，依次对每个模式的影响进行抽象地表示。于是，Command模式创建了TestCase类，Template Method模式创建了run方法，等等。（情节图板的标记是在图6中标记的基础上删除了所有的文字）。

图7 JUnit模式的情节图板

　　关于情节图板有一点要注意的是，图的复杂性是如何在我们应用Composite时进行跃迁的。其以图示的方式证实了我们的直觉，即Composite是一个强大的模式，但它会“使得图变得复杂。”因此应该谨慎地予以使用。

　　4 结论

　　最后，让我们作一些全面的观察：

　　· 模式

　　我们发现从模式的角度来论述设计是非常宝贵的，无论是在我们进行框架的开发中，还是我们试图向其他人论述它时。你现在正处于一个完美的位置来判定，以模式来描述一个框架是否有效。如果你喜欢上面的论述，请为你自己的系统尝试相同的表现风格。

　　· 模式密度

　　TestCase周围的模式“密度”比较高，其是JUnit的关键抽象。高模式密度的设计更加易于使用，但却更加难于修改。我们发现像这样一个在关键抽象周围的高模式密度，对于成熟的框架而言是常见的。其对立面则应适用于那些不成熟的框架－它们应该具有低模式密度。一旦你发现你所要真正解决的问题，你便能够开始“浓缩（compress）”这个解决方案，直到一个模式越来越密集的区域，而这些模式在其中提供了杠杆的作用。

　　· 用自己做的东西

　　一旦我们完成了基本的单元测试功能，我们自身就要将其应用起来。TestCase可以验证框架能够为错误，成功和失败报告正确的结果。我们发现随着框架设计的继续演变，这是无价的。我们发现JUnit的最具挑战性的应用便是测试其本身的行为。

　　· 交集（intersection），而非并集（union）

　　在框架开发中有一个诱惑就是，包含每一个你所能够具有的特性。毕竟，你想使框架尽可能得有价值。然而，会有一种阻碍－开发者不得不来决定使用你的框架。框架所具有的特性越少，那么学起来就越容易，开发者使用它的可能性就越大。JUnit便是根据这种风格写就的。其仅实现了那些测试运行所完全基本的特性－运行测试的套件，使各个测试的执行彼此相互隔离，以及测试的自动运行。是的，我们无法抵抗对于一些特性的添加，但是我们会小心地将其放到它们自己的扩展包中（test.extensions）。该包中有一个值得注意的成员是TestDecorator，其允许在一个测试之前和之后可以执行附加的代码。

　　· 框架编写者要读他们的代码

　　我们花在阅读JUnit的代码上的时间比起编写它的时间要多出很多。而且花在去除重复功能上的时间几乎与添加新功能的时间相等。我们积极地进行设计上的实验，以多种我们能够想出的不同方式来添加新的类以及移动职责。通过对JUnit持续不断地洞察（测试，对象设计，框架开发），以及发表更深入的文章的机会，我们因为我们的偏执而获得了回报（并将依然获得回报）。