12.3  汇点的陷阱

在编写单元测试的时候我们可能会遇到各式各样的麻烦。其一就是我们的单元测试可能会缓慢但逐步地演化为“迷你型”的集成测试。一般来说情况是这样的，开始的时候我们需要测试一个类，所以实例化了好几个被它用到的类，并将实例化出来的对象传递给该类。我们检查某些值，而且相信这组类互相“合作愉快”。但这种做法的缺点在于，一旦它被过于频繁地使用，最终就有可能演化成庞大而笨重的、不知何年何月才能运行完成的“单元测试”来。要想避免这一点，比如我们在给新代码编写单元测试的时候，就要尽可能单独而孤立地去测试它们。一旦意识到手头的测试已经过于笨重了，就应该去分解被测试类，分解出较容易测试的独立小类来。另外我们还不时需要去伪造被测试类所需要用到的某些对象，因为单元测试的任务并非检查一簇类是否能够合作良好，而是检查单个的对象行为是否正确。通过伪造合作类对象我们就可以更容易地达到这一目的。

然而，以上只是对新编写的代码而言；在给既有代码编写测试时，情况就反过来了。往往比较好的做法是把程序中的某一块切割下来，利用测试来坚固它。当这些测试都安置到位之后，我们就可以更容易地为这块区域内的每个类编写更狭窄的单元测试了。然后，最终当这些单元测试全都完成，原先在汇点编写的测试也就可以功成身退了。

在汇点编写测试就有点像走了几步进入一片森林，然后划一条线，说：“这块地方现在是我的了。”然后，在拥有了这块（代码）区域之后，你就可以通过重构和编写更多的测试来改善它。而随着时间的推移，你将可以扔掉原先在汇点编写的那些测试，而让每个类的单元测试来支持自己的开发工作。