单元测试
什么是单元测试
单元测试是指对最小可测单元进行检查和验证。最小可测单元可以是一个函数，一个类，一个窗口，一个菜单， 根据不同的场景来找出最小可测单元。例如： 工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。 开发人员有责任编写功能代码，同时也有责任为自己的代码编写单元测试。
为什么要编写单元测试
- 验证代码正确性
- 修改代码时能最大程度确保不影响其它功能
- 为了达到代码可测性，我们会尽可能优化结构，保证最小单元的单一职责
- 需求规格的可追溯性
- 最终达到的目的可维护性高，上线前有改动不再提心吊胆，少加班。
成本效率
两种态度：
赞成：
* 学习新知识， 提高技能。(长时间吃老本是没前途的)
* 验证提交的代码的正确性。（个人觉得只出于这种目的的，性价比不高）
* 安心重构，安心修改代码。
* 应对产品、UE莫须有功能需求指责的有力武器。
* 从中获取到好处，成习惯了，写完代码不写单元测试就全身不舒服。(本人还没到那种境界，瞎猜的)
反对：
* 单元测试是啥？ 没写过，不会。
* 在这个项目上呆两天就跑了，花那么大功夫干嘛，吃力不讨好
* 时间，时间，还是时间
在此本人不下定论，只罗列一些网上搜集的观点和一些自己的看法。
它太浪费时间了，如果在项目中进行单元测试，势必会影响开发者的项目进度。答案是肯定的，在实践工作中进行了完整计划的单元测试和编写实际的代码所花费的精力大致是相当的。产出品质可以久经考验的产品，必然要花费较多的精力，如果只是豆腐渣工程，自然可以快速产出。区别在于后续的维护差异，因为单元测试的质量保障，你可以放心的增加和删除功能，后者则会陷入举步维艰的维护之路，拆东墙补墙，开发者也渐渐变的只想做新项目，而旧的项目变得不可维护，甚至不敢维护，甚至到下线时，依然充斥着幽灵代码和重复代码。单元测试只是在早期会多花一定成本，但这个成本要远远低于后期深陷维护泥潭的投入。
它仅仅证明了这些代码做了什么。产生这种抱怨肯定是由于PM, UE前期对产品、功能规格定义不够以及我们开发者在没有完整理解需求规格的情况下就开始编码，边写边去理解需求。当代码完成后面临测试任务时，只能去阅读这些代码并找出他实际做了什么。 如果一开始就有一个详细的规格说明，那么测试就能以规格说明为基础，就能针对需求规格，而不是代码本身进行测试。
我是一个很棒的程序员，不需要单元测试。 我只能 呵呵 了。