开发需要写单元测试吗？

我们这个行业里很多弔诡的事，可以缩影到这一件：所有人都赞同单元测试非常重要，然而很少人做单元测试。

有很多公司非常准确地把单元测试叫做“开发自测”，并且非常准确地认识到了这个活动的重要性：程序员只要认真测一测自己写的代码，bug就能减少90%。至于时下流行的敏捷么，我毫不夸张说一句：一切没有充分单元测试覆盖的敏捷都是伪敏捷。别的啥都不说了，没有充分的单元测试覆盖，你持续集成跑啥？持续集成不能保障软件质量，靠测试人员跟在屁股后面人肉回归么？

但是就这么一件所有人认可其价值、所有人都重视的事，我们这个行业里，我客气点说，80%的企业落不了地。这难道不是一个值得玩味的文化现象么？

为什么会这样呢？我这儿一家之言：因为整个行业都被软件工程教材给误导了。

软件工程教材说，代码应该有单元测试。这没错，但这话没说完，因为它只描述了一个结果状态。怎么去到这个结果状态的过程，它没有说。什么时候写单元测试？怎么写？单元测试和产品代码之间怎么配合？什么时候运行单元测试？这些每天工作的细节，教材里全都没有。

单元测试通常被认为是编码阶段的附属工作。可以在编码开始之前或源代码生成之后进行单元测试的设计。设计信息的评审可以指导建立测试用例。每个测试用例都应与一组预期结果联系在一起。——《软件工程：实践者的研究方法》（第7版）

实践者们看了这个，能知道怎么动手写单元测试么？于是大家就只好靠猜。想必一定是先写好产品代码再写单元测试来测它吧？一定是这样的！卡桑，我这就可以报效祖国去了吧！

然后一写发现满不是这么回事。因为在写代码的时候并没有考虑这代码要怎么测，所以写完了以后要测发现很难，找不到接缝，测不动。这时候交付压力又紧逼着，唉，要不先放着改天再测吧。当然我们都知道，这个改天再做的事就再也不会做。

我们这个行业里有很多事都类似这样。有一些大师告诉你，这事应该怎么怎么做。但是他其实并没有告诉你“怎么做”，而是告诉你“做成了之后是什么样”。他给你的是一个结果状态，而不是怎么达到这个结果的过程。