单元测试的局限
关于单元测试的一篇好文章，我只翻译了一段，有兴趣的可以看看原文。

译自：http://www.theserverside.com/blogs/showblog.tss?id=Unitized

考虑一下单元测试的目的和原则：
1。尽量小粒度的“单元”被测试。
2。测试在于其它模块隔离地情况下独立地完成。
3。Mocking在隔离的方面作出了强化。
4。代码和测试都是同一个人完成的。

把上面提到的考虑在一起，意味着单元测试是测试整个代码中最低层次的部分，每一个部分是和其它部分隔离的。测试和编码是同一个人完成的。
这种方式的测试正是“我”所说的“low hanging fruit”[可轻易实现的目标 (easy targets)]。它可以捕获小的问题，也就是可以找到不符合单元测试的要求的单独的函数或者类。

单元测试是一个好事，提供了对于自己代码正确性的有价值的反馈。但是“Keep in mind" 它只能得到“low hanging fruit”。在设计上，单元测试被期望“简单的”、“作为系统中独立的小部分”。因为这些，在它的本质上（与生俱来的），单元测试没有考虑系统的“组合”，它只考虑独立的部分。单元测试从不检查一个系统中内部的联络，从不检查他们是如何捆绑在一起的。

根据“我”的经验，系统中如何联络和如何捆绑在一起正是系统的复杂度所在。
正是这种“连接”定义了你的设计，如果在一个足够高的层次上考虑，这种联系甚至可以理解为系统的架构。
信息是如何在不同的软件层上和不同的组件之间的流动实实在在的定义了一个应用。
由此看来，单元测试是不会测试一个应用的这些方面的。单元测试忽略了信息是如何在不同的层和不同的组件之间流动的，忽略了类和对象在一个大的架构和设计中如何相互关联和组合在一起的。
这就意味着单元测试只能在独立的代码片断中捕获简单的错误，但是对系统的整体的设计或者机构Say nothing。
设计和架构限定了你的系统的性能，内存使用，“端到端”的正确性。[用户的输入，到Server处理所使用的，到最后的返回的整个路径]。所以这些是如何进行联系的显示了系统的行为，并且正是在这个范围中存在着the toughest bug 和 problems，要想让一切OK，程序员们也要在这个地方苦干不止。
编写隔离的独立组件是容易的，把他们粘合在一起是困难的。单元测试只在隔离的在独立的部分上作判断，而不是在整体上。

使系统中的一个组件的动作正确相当来说是价值不高的活动。独立的编写一个系统的组件不是计算机编程的困难的部分，任何一个个体的小的组件都是容易编写的。在开发中最难的部分来自于如何把所有的组件捆绑在一起工作。单元测试可以验证每一个你编写的独立组件是不是按照你所想的那样工作，但是它不能检查更复杂的“wiring”--“wiring”正是我们的设计，开发和调试绝大部分工数所在。

从上看来，单元测试不会指出“端到端”的处理是否正常，不会关心性能，不会关心内存的使用，不会关心可用性，不会关心代码是否正是用户想要的。它也不会捕获多线程的bug，或者错误的理解了外部API或者子系统的使用等等。这些并不意味着单元测试是不好的或者应该避免的，它只是说明单元测试只会给你一个有限的回报。设想我们作为开发人员，我们没有无限的资源去开发我们的代码，我们不得不聪明的决定我们要把我们的精力放在那里。我们不得不经常的折衷和决定怎样做有最好的效果。

在“我”参加的所有开发中。单元测试覆盖了绝大部分的代码，但是在以下的方面的努力还差得很远：
1。应用程序设计的本身。你应该花费更多的时间在你的设计上，采用一种迭代的，真实地方式而不是花费在单元测试上，因为一个好的设计得到的回报比任何数量的单元测试都多。
2。集成测试（Integration Test）。集成测试的测试特征是基于“端到端”的。通过它的设计可以证明你的独立的组件可以工作在一起。通过一个集成测试，你可以更信赖你的系统按照“端到端”的方式工作，而不是一些独立的对象。
3。功能测试和回归测试（Functional Test&Regression Test）。系统不是开发人员想的那样，而是用户期望它是什么样子。更进一步，回归测试当新的特性被追加或者底层的代码被改变时，验证高级别的功能的正确性没有被改变。
4。非功能测试（Non-function Test)。在可接受的运行需求下，代码作为整体被运行，请求在可接受的时间范围内被处理。sever不会因为有3个用户请求就会memory紧张。等等。

做以上的东西会比单元测试难很多。但是在同样的投入下会得到更多的回报。