为什么要编写单元测试？原因是单元测试有不少的优点，能够给我们的工作带来很大的帮助。

　　单元测试的优点

　　1. 帮助开发人员编写代码，提升质量、减少bug。如果大家分析一下我们bug原因的构成，我想有会有一部分bug的原因是开发人员在编写工作代码的时候没有考虑到某些case或者边际条件。造成这种问题的原因很多，其中很重要的一个原因是我们对工作代码所要完成的功能思考不足，而编写单元测试，特别是先写单元测试再写工作代码就可以帮助开发人员思考编写的代码到底要实现哪些功能。例如实现一个简单的用户注册功能的业务类方法，用单元测试再写工作代码的方式来工作的话

　　开发人员就会先考虑各种场景相关，例如正常注册、用户名重复、没有满足必要的填写内容......等等，之后就会编写相关的测试用例

　　编写单元测试代码的过程就是促使开发人员思考工作代码实现内容和逻辑的过程，之后实现工作代码的时候，开发人员思路会更清晰，实现代码的质量也会有相应的提升。

　　2. 提升反馈速度，减少重复工作，提高开发效率。开发人员实现某个功能或者修补了某个bug，如果有相应的单元测试支持的话，开发人员可以马上通过运行单元测试来验证之前完成的代码是否正确，而不需要反复通过发布war包、启动jboss、通过浏览器输入数据等繁琐的步骤来验证所完成的功能。用单元测试代码来验证代码和通过发布应用以人工的方式来验证代码这两者的效率差很多，看到很多开发人员每天要反复执行N次发布脚本（antx之类的工具）真是痛苦。

　　3. 保证你最后的代码修改不会破坏之前代码的功能。项目越做越大，代码越来越多，特别涉及到一些公用接口之类的代码或是底层的基础库，谁也不敢保证这次修改的代码不会破坏之前的功能，所以与此相关的需求会被搁置或推迟，由于不敢改进代码，代码也变得越来越难以维护，质量也越来越差。而单元测试就是解决这种问题的很好方法（不敢说最好的）。由于代码的历史功能都有相应的单元测试保证，修改了某些代码以后，通过运行相关的单元测试就可以验证出新调整的功能是否有影响到之前的功能。当然要实现到这种程度需要很大的付出，不但要能够达到比较高的测试覆盖率，而且单元测试代码的编写质量也要有保证。

　　4. 让代码维护更容易。由于给代码写很多单元测试，相当于给代码加上了规格说明书，开发人员通过读单元测试代码也能够帮助开发人员理解现有代码。很有opensource的项目都有相当量的单元测试代码，通过读这些测试代码会有助于理解生产源代码。

　　5. 有助于改进代码质量和设计。除了那些大拿们编写的代码，我相信很多易于维护、设计良好的代码都是通过不断的重构才得到的。虽然说单元测试本身不能直接改进生产代码的质量，但它为生产代码提供了“安全网”，让开发人员可以勇敢地改进代码，从而让代码的clean和beautiful不再是梦想。

　　单元测试的缺点

　　1. 单元测试的学习成本比较高。编写单元测试涉及的技术很多，如果只是单纯的使用Junit或是TestNG这样的基础单元测试框架往往很难应对各种复杂的单元测试情况，所以势必要借助很多第三方的框架和技术（easymock，jmock，dbunit等等），这些框架和技术的学习还是会增加学习的成本和难度。

　　2. 编写单元测试会增加程序员工作量。单元测试跟生产代码是一样的，并不会应为是用来测试的就有所不同，开发人员同样要面对测试代码的编写、维护等工作，也同样要面对避免重复代码等一系列问题，能否写出好的测试代码还是取决于开发人员的设计和编码能力。

　　3. 推广和运用单元测试需要比较大的投入。只有在每个开发人员都编写了足够的、质量好的单元测试代码，大家才能真正享受到单元测试带给我们的好处。在达到这种层度以前，还需要不少实现和资源的投入。

　　总结

　　虽然单元测试也有一些缺点和负面的效应，但跟单元测试的优点比较起来，为了克服和解决这些缺点所在的付出是值得的。