单元测试要不要做?这件事,IT业的基本共识是,做了比不做好。但基本的现状是,说得多,做得少

首先,单元测试谁来做?答案是,开发人员自己做

其次,什么时候做?当然是写代码的时候,一起做把单元测试作为交付代码必不可少的交付物一起完成。没有单元测试的代码,不能算完成。

但现实中可不是这样子。我们来看看大家是怎么说的。

“之前我们单位没有强制要求过写单元测试。现在要推这个,但是没有几个组愿意主动尝试。。。。。。”

“有想过强制推行,但是一些开发同事认为会耽误需求进度,所以阻力也比较大。”

“先要大家统一认识。了解好处,然后找几个人做实验。”

“定最低覆盖率,做不到走人,做好的奖。都达到最低要求了,就成为常态。”

“我们定60%的单元测试覆盖率最低要求,高的奖,达不到走人,先走数,再有量。先走数,再抓质量。过程中可以提要求,比如断言数的覆盖率。然后抽查,抓典型问题。”

“我们领导建议较少采用行政手段。。这个我就比较为难。”

“如果一开始就有这个文化,不是问题,中途推,就比较麻烦,或者 建典型团队。”

“实验是为了找出几个有意愿的人,所以我想找几个组先试验还是比较折中。他们几个做出来效果,给别人说才能起到有力的作用吧,比如质量明显提高。”

“技术经理或负责人愿意配合吗?得有人领着做和抽查质量。我这面最后技术经理都没招了,他跑了单元测试就半荒废了。如果有个别负责人愿意配合,要把握好‘志愿者’。”

归根结底,大老板必须在行政手段上干预,他不想上行政手段,就是不想担责任。老板不承认单元测试的强制性,那工期压力上来,单元测试必然是要牺牲掉的,即使程序员都是高素质,但也是要在乎个人利益的,公司耽误了,说是因为单元测试的原因,老板肯定是不买账的。所以我不觉得行政手段是可有可无的,有奖有罚才有效。

自动化测试也是一个道理,总要有人写自动化测试脚本,如果软件架构对自动化测试支持不好,还要改架构。自动化测试也是要写脚本和代码的,领导不支持也白搭。

单元测试时程序功能的基本保障,不是要不要做,而是一定要做,我不太清楚为什么现在的团队很多 程序员自己都不做单元测试了。这个在早前的团队中是不容许的,是每一个程序员必须要做的的事情。和时间没有关系吧。为了赶进度就牺牲了,就做得少或不做了。 除非你的项目时间非常充裕,什么时候完成都可以。

“单元测试时基本性的测试,如果不做,光是靠测试人员去验证功能,很可能质量无法保障啊,现在我们的团队也是有的人做了,有的人没做。有很多程序员居然都不知道需要做单元测试了。开始我以为是我们团队的人员上有问题造成的,今天看大家讨论,感觉貌似是个普遍现象了。”

“你说的单元测试是写UT代码的那种单元测试吗?对于有非常严格的上线时间的项目,不写单元测试代码都不见得能完成工期。这种情况你们是怎么做的?”

“我们之前和楼上的是一样的,压根没有。上线项目都是测试人员直接上手测试的。忽略了单元测试代码的构建。开始的时候还可以,但是做过一段时间后,发现需求有变化时,测试人员的测试力度或者测试范围覆盖不了修改Bug的点,而且频繁的修复,发现时间上不没有因为这些而节约,反而比预想的增多了。只能靠加班时间来弥补。”

“但是,其中也有的人员,进行单元测试。反而这部分人的代码质量就偏高一些,测试出错的几率也下降了。所以我们也想开始实现全员的单元测试。我做开发那会,CMMI管理方式,我们是必须交单元测试报告,SCM才同意合并分支,现在一天自动集成几次,不好控制了。连代码review 都成形式了。”

“目前也在摸索中,不过我们目前是行政推进,给大家学习的时间,验证的时间,之后就全员推行。道理大家都懂,关键还是要老大行政支持,否则真白扯。”

用友公司经理罗涛的点评:

单元测试这块,各个公司都是痛,表现不一样,我们现在分化比较厉害,有严格要求开发必须做的,也有瀑布模型,根本不做的,有项目压力的,一般都简化了,传统管理者习惯思维认为有那时间多写点代码不好吗?写测试用例?

听以前的同事,后来到百度的,讲过一个实际例子,没有单测和自动化时候,单元阶段和集成阶段发现的bug 数是1:1的比例,进行了单侧并且自动化回归後, 单元阶段和集成阶段发现的bug 数变成是10:1的比例。

体验到好处的团队会坚持,从没感受到好处的团队会拒绝,而且是坚决的拒绝。也是基于这个原因,我们是强制要求了,先形成这个氛围再说。

这时候验收测试部的老大急了,训斥验收测试的测试人员你们干嘛吃的,都不好好测试了?后来在极强的测试人员工作强度下,基本上还是这样。好处是,原来及其耗时的集成测试,同比压缩近半,整体发布周期提升近30%。

还有,中兴某团队,有测试的时候,质量问题相当到一个水平后,保持不变。后来,测试怀孕了,生孩子去了,没测试了。团队自测,互测,开始一段你会发现问题数上升了,质量下降,但经过一段时间后,低级bug数快速下降,质量极大提升,团队效率更大提升,测试归队后,自己也提升去进行基于客户的探索性测试,进一步提升产品质量和竞争力,步入良性循环。

所以,要借势,造势,团队有意愿,要积极扶持,给政策,允许并容忍短期的效率和质量的下降,为长期的提升打基础。但现实是很多决策者既得利益者,害怕承担风险,所以拒绝变革,这是人性使然。

作为教练,everything is okay!我们要理解这种情绪,所以尽量先在小团队或者那种被认为很烂的团队去推动这种变革,因为他们如果不变,也是死,变还有活路,而且一旦成功,那就厉害了word哥啊!这个京东的某个团队很典型呢!