单元测试有三个方面的作用：

1、测试代码行为；
2、改进代码设计；
3、作为文档。

其中第一点是单元测试的直接目的。很多人认为只要有了足够的单元测试，就能够保证代码的高质量。但问题是很多代码难于写单元测试，比如 JSP 和 Servlet，Struts 1.X 的设计也对单元测试不友好。我们需要借助其他的包或者一些手段来对它们进行单元测试。这就自然的引出了单元测试的第二个作用：改进代码设计。

代码设计的改进带来的好处不仅仅体现在单元测试方面。有了好的设计，一旦需求有变更，开发人员也能更加轻松的实现，而且 BUG 更少。这也是很多项目管理人员对单元测试青睐有加的原因。但是从很多实践来看，能够最大发挥这个作用的只有测试驱动开发（Test-Driven Development）。想想看，如果单元测试不能对设计阶段施加影响，就谈不上对设计的改进；而设计阶段产生的是文档而不是代码，自然没有单元测试。这个矛盾使很多项目的单元测试无法发挥应有的效果。而测试驱动开发将测试作为设计的一部分，在经过粗略的构思之后，提笔就写测试，然后写代码，通过不停的完善测试，最终形成一个能够流畅运行单元测试的系统。这个系统不但有足够的单元测试保证其行为，而且也是设计良好的。

我们当前许多项目中，设计人员和开发人员各司其职，基本上互不通气；单元测试是开发人员的事情，开发人员对于改进设计缺乏主动性，甚至是被禁止的。这使得单元测试陷于两难境地：一方面糟糕的设计使得写单元测试比写代码本身还难，另一方面单元测试无法改变糟糕的设计。单元测试成了吃力不讨好的东西。而管理者仍认为代码质量不佳是单元测试没有“到位”，于是再加上一堆的文档试图将单元测试“规范化”，单元测试更加成了一个累赘。

这不是单元测试本身的责任，这都是对单元测试的误解造成的。只要单元测试不能对设计施加有效影响，单元测试就只能陷于这种被动的境地。

协调沟通最麻烦