开发需要写单元测试吗?
我们这个行业里很多弔诡的事,可以缩影到这一件:所有人都赞同单元测试非常重要,然而很少人做单元测试。
测试开发:零基础自学搭建自动化测试平台实战速成
有很多公司非常准确地把单元测试叫做“开发自测”,并且非常准确地认识到了这个活动的重要性:程序员只要认真测一测自己写的代码,bug就能减少90%。至于时下流行的敏捷么,我毫不夸张说一句:一切没有充分单元测试覆盖的敏捷都是伪敏捷。别的啥都不说了,没有充分的单元测试覆盖,你持续集成跑啥?持续集成不能保障软件质量,靠测试人员跟在屁股后面人肉回归么?
但是就这么一件所有人认可其价值、所有人都重视的事,我们这个行业里,我客气点说,80%的企业落不了地。这难道不是一个值得玩味的文化现象么?
为什么会这样呢?我这儿一家之言:因为整个行业都被软件工程教材给误导了。
软件工程教材说,代码应该有单元测试。这没错,但这话没说完,因为它只描述了一个结果状态。怎么去到这个结果状态的过程,它没有说。什么时候写单元测试?怎么写?单元测试和产品代码之间怎么配合?什么时候运行单元测试?这些每天工作的细节,教材里全都没有。
单元测试通常被认为是编码阶段的附属工作。可以在编码开始之前或源代码生成之后进行单元测试的设计。设计信息的评审可以指导建立测试用例。每个测试用例都应与一组预期结果联系在一起。——《软件工程:实践者的研究方法》(第7版)
实践者们看了这个,能知道怎么动手写单元测试么?于是大家就只好靠猜。想必一定是先写好产品代码再写单元测试来测它吧?一定是这样的!卡桑,我这就可以报效祖国去了吧!
然后一写发现满不是这么回事。因为在写代码的时候并没有考虑这代码要怎么测,所以写完了以后要测发现很难,找不到接缝,测不动。这时候交付压力又紧逼着,唉,要不先放着改天再测吧。当然我们都知道,这个改天再做的事就再也不会做。
我们这个行业里有很多事都类似这样。有一些大师告诉你,这事应该怎么怎么做。但是他其实并没有告诉你“怎么做”,而是告诉你“做成了之后是什么样”。他给你的是一个结果状态,而不是怎么达到这个结果的过程。