实践单元测试(2) - 大话单元测试

...
我知道这个项目bug很多，无法按时完成，即使老板把我炒了也是应该的。曾经有一个做单元测试的机会放在我面前，我没有珍惜，等到后来项目雪崩了才后悔。如果上天能再给我一次机会，我会对老板说：我要做单元测试！如果一定要在单元测试上加个日期，我希望是一直。
...

在这里我并不是想说该怎么样去进行单元测试，既然我们无法规定该如何编写产品代码去实现需求功能，同样也不能要求开发人员该如何编写测试代码，甚至是否要编写UT。

劝服项目经理在项目中实施单元测试更是难上加难，因为单元测试对PM来说往往意味着需要更长的开发周期，更多的成本投入，而且按照传统的方式一样也能完成项目，赚到钱。于是面对着紧张的工期，在项目中拍板实施单元测试的确需要魄力和权衡。

但正是这样的理解误区导致了UT在国内难以推广，我认为对于整个开发周期而言，单元测试可以缩短开发时间，提高产品质量，起到降低成本和规避风险的作用。下面我们看看在代码编写过程中都把时间花在哪了：

1、学习和阅读代码：对于项目组的新成员或着是当使用别人编写的服务时，往往需要阅读他人的代码，UT提供了最佳示例，可节省学习时间和成本。
2、编写产品代码：无论是否实施UT，这都是必须的。
3、修改产品代码：在未引入UT时，产品代码的bug往往要等到质量部门或这是客户试用时才能发觉，更甚至是到系统运行一段时间后才会出现，当然UT并不能完全避免bug的产生，但是能够帮助我们尽早的发现bug，及早解决问题，往往可以节约开发时间和成本。
4、重构：这点小项目就谈不上了，但是对于大项目，没有UT也敢说进行重构的确是需要超人的勇气！我更倾向于认为没有实施UT的项目是不可重构的。


不过我也没有参与过全程实施单元测试的项目，上面的话也是一番空讲，期望您的意见。