单元测试保证局部代码的质量
　　单元测试在隔离的前提下，分别对各个代码单元进行测试，能够达到其他测试不可能达到的测试完整性，从而保证了局部代码的质量。只有局部代码的质量得到了保证，软件产品的质量才可能得到保证。
　　单元测试改良项目代码的整体结构
　　要对代码进行单元测试，起码的前提是代码能够隔离，也是说，要具有一定的可测性，因此，单元测试是一种有效的约束机制，这种机制将有效地改良代码的整体结构。例如，如果把业务代码直接写在界面类中，将很难进行单元测试，随意的不合理的紧耦合也会造成难于测试，单元测试使这些不好的特性得于及时发现，从而很容易进行修正。可测性是高质量代码的首要特性，不具有可测性，也无法衡量代码的正确性，有了可测性，也基本上保证了代码的可扩展性、可复用性。
　　单元测试降低测试、维护升级的成本
　　错误越早发现，修复的代价越小，另一方面，如果代码经过了充分的单元测试，集成测试和系统测试只需要关注设计方面的问题。自动回归测试也大量降低升级维护成本。
　　使开发过程适应频繁变化的需求
　　单元测试自然地使开发流程变得“敏捷”，这是因为，整体结构良好的代码具有较好的可扩展性，自动回归测试又能保证修改不会引入新的错误，因此可以适应频繁变动的需求，降低系统分析、架构设计和后期测试的压力。
　　单元测试有助于提升程序员的能力
　　对程序员来说，单元测试有利于养成缜密的思维习惯，及提高设计能力。
　　由谁进行测试?开发部门还是测试部门?
　　应该由开发部门进行单元测试!
　　由测试部门进行单元测试的问题
　　代价高：反复的重新理解代码需要大量的时间，反复的沟通也需要大量的成本。
　　人手不足：进行单元测试的人员需要具备编码能力，很多软件企业的测试部门都没有足够的人手。
　　耽误了测试部门对其他测试的准备工作：编码阶段，测试部门要为集成测试、系统测试等做好准备，如果测试部门陷在单元测试的“泥潭”里，很可能影响这些准备工作。
　　由开发部门进行单元测试的问题
　　担心影响开发进度：这是现实问题，但自动化的单元测试工具可以解决这个问题。
　　程序员不习惯做单元测试：这种习惯是可以理解的，但并不难改变，实际上，程序员写程序时都是要进行测试调试的，只不过通常比较零散和随意而已。
　　测试自己编写的代码，难于保证测试的效果：测试自己写的代码，通常会只测试正常的输入，因此难于保证测试的完整性，但自动化的单元测试工具，可以统计白盒覆盖，甚至提供用于找出遗漏的测试用例的工具，达到很高的测试完整性。只要达到了足够的测试完整性，那么，无论谁测试，效果都是一样的。
　　无论由哪个部门做单元测试，都要面对一些问题，但开发部门所面对的问题可以借助工具来解决，而由测试部门进行单元测试，要么无法真正实施，要么代价昂贵。