3、单元测试的必要性

　　3.1    不做单元测试的后果

　　项目进度的黑洞

　　*      完成99%（最后的1%永远无法完成）

　　*      2个月完成开发，半年过去了还是不稳定

　　*      骨干员工都投入在维护以前项目上

　　*      没有力量进行新的研发

　　*      越来越难维护，导致产品开发难以创新

　　研发成本的大量消耗

　　骨干员工才能进行维护

　　*      由于模块间耦合，只有骨干才了解整体情况

　　*      骨干每天都在Debug（没有力量进行新的研发）

　　问题的解决周期(8小时)

　　*      定位问题4~6小时

　　*      解决问题1~2小时

　　*      浪费了（4/5=80%左右的维护工作量）

　　软件质量故障延迟解决的代价

　　*      开发人员提交了带有隐患的代码

　　*      测试人员可能轻易发现故障、可能很难发现故障

　　*      发布到生产环境中的故障被用户使用时发现

　　*      我们的软件运行不稳定

　　难以为继

　　*      为了修正问题的改动缺少整体考虑

　　*      可维护性不断下降

　　*      不同维护人员思路不同（时间长了容易出现冲突）

　　*      长期的结果是导致代码必须重写

　　3.2    单元测试的优点

　　是一种验证行为

　　*      不会出现项目进度的黑洞

　　*      完成的功能都得到了验证

　　*      不会出现产品不稳定的情况

　　*      不用担心修改导致程序结构被破坏

　　*      任何人都可以维护项目

　　*      不用担心修改导致程序结构被破坏

　　*      快速的定位问题

　　*      通过运行单元测试定位问题

　　*      不会出现难以为继的现象

　　*      每一项功能都是测试来验证它的正确性

　　是一种设计行为

　　*      迫使我们从调用者角度考虑

　　*      迫使我们把程序设计成为可调用和可测试的

　　*      迫使我们接触模块之间的耦合

　　是一种编写文档的行为

　　*      一种无价的文档

　　*      类或方法如何使用的最佳文档

　　*      文档是可编译、可运行的

　　*      保持最新永远与代码同步

　　具有回归性

　　*      单元测试用例可以随时运行

　　*      单元测试用例可以做到自动化批量运行

　　*      是我们的软件能够持续构建的基石

　　注：3.1和3.2节参 leemingjun《单元测试的必要性和可行性 》