写作单元测试代码的好处

　　熟悉单元测试技术，了解相关的基本原理；

　　掌握代码，积累代码编写经验，积累调试经验，积累分析问题、解决问题的经验；

　　训练动手能力，单元测试代码不是业务代码，开发、维护过程中不需要特别关注质量要求，底限是达到验证业务代码逻辑性的目的，因而比修改代码要省心、省事；

　　不需要准备项目运行环境，单元测试代码在运行时的外部依赖比较少，执行验证、调试代码的代价会很低；

　　降低新手程序员进入项目的门槛，有助于积累信心。

　　项目过程中写单元测试的好处

　　一边写代码，一边检查代码中的小错误或者小疏忽，提前解决代码中可能存在的笔误；

　　为了让单元测试代码更好写，需要花点心思在思考类和方法的结构，好处是可以有效的提升代码的可测试性，否则设计和结构不理想时，单元测试代码写作时也会比较麻烦，需要打很多桩；

　　在集成测试前，有机会做验证模块内部的逻辑正确性，避免在联调时花费过多的时间来解决小问题，提高联调的效率；

　　单元测试代码对运行环境依赖小，不需要特别准备复杂的环境，外部模块的行为和表现是可控制的，易于模拟异常场景；

　　记录已实现的特性，代码即是最好的文档，设计良好的单元测试代码有助于后续维护，降低后期修改引入问题的可能性。

　　维护或者学习代码过程中写单元测试的好处

　　熟悉已有代码的逻辑，变量的变化方式，代码的运行轨迹，提高学习代码的效率，降低通过看代码来学习代码的负担；

　　帮助重构，提高重构的成功率；

　　辅助问题分析，遇到问题时，可以借助分析单元测试代码来了解模块的一般行为。

　　单元测试的缺点

　　单元测试并不万能，并不能解决所有问题，受限于测试范围和场景以及数据，只能满足单模块内部的功能验证的需求；

　　单元测试覆盖分支，系统测试覆盖场景，二者可能存在重叠，另由于着眼点不同，二者不能相互替代，测试覆盖率有不同的含义；

　　部分之和不等于整体，单纯追求覆盖率是可笑的，覆盖率只是衡量测试投入的指标，和代码质量并没有直接的关联，另外当覆盖率达到一定程序之后，继续提升覆盖率时投入和产出可能不成正比，效益可能会下降；

　　同样，单元测试用例数目和代码行之间的比率高也不能说明代码质量一定好；

　　不能解决或者发现模块可靠性、性能相关、多线程访问相关的问题，这几类问题还是要从设计上分析，编码时注意，单元测试在应对这几类问题前面效果不好；

　　已有的单元测试代码也需要投入时间和人力来维护，特别是业务变更频繁或者其它原因导致的业务代码频繁变更，同步维护单元测试代码就是一个噩梦；

　　如果项目需要开发人员写作单元测试，则在项目计划时要充分考虑团队中成员的能力，为单元测试代码开发预留时间，否则美好的愿望最终将无法实现。