你真的需要单元测试吗?

单元测试不是用来找Bug的

当你看到网上诸多关于单元测试的赞美时，仔细看看你就会发现很多说的其实是TDD(Test-Driven Development，测试驱动开发)，不幸的是大多数人并没有注意区分这两个概念。在Writing Great Unit Tests: Best and Worst Practices中，Steven Sanderson强烈表达了自己的观点：Unit testing is not about finding bugs。简单来说，当先写代码后写单元测试的时候，单元测试就成了一种发现Bug的手段，但作者根据其几十年的开发经验指出这种手段其实是十分低效的，因为即使每个功能模块都能正常工作，但是仍然不能保证模块之间、模块与用户环境之间能正确交互，而后者往往是Bug的主要来源。单元测试或许能找到一些Bug，但相比集成测试和系统测试就显得十分低效了。
既然如此，那么单元测试为何又备受追捧呢？在How Google Tests Software中，三位谷歌的专家介绍了谷歌的软件测试之道，总而言之就是谷歌会在开发之初设计好单元测试（其实是用代码表达需求），在开发中不断迭代以通过全部的测试（其实是完成全部需求），最终交付给测试人员的软件已经经过一轮测试，如果还有集成后的Bug，就可以交给专业的测试人员发现了。这是一种典型的敏捷开发，可以看到单元测试扮演更多的是驱动开发的角色。
作为技术标杆的谷歌已经全面引入了单元测试，那么我作为一个普通开发者为什么还要提出一番质疑呢？请看下一节。

单元测试的边际收益

在经济学领域，有一个著名的边际收益递减规律，指在投入生产要素后，每单位生产要素所能提供的产量增加发生递减（二阶导数为负）的现象。在本文讨论的场景中，投入产出如下（引自：软件开发过程中值不值得写单元测试？ - voidint’s blog）：

成本(投入)
* 编写单元测试用例所额外付出的时间，短期内会拖慢项目进度。

收益(产出)
* 提升代码质量。监督开发人员写出更加易于测试和可维护的代码。
* 提升开发团队内部的协作效率。其他开发人员可以通过阅读单元测试用例来理解代码原作者的意图。
* 保证功能实现的长期稳定。代码一旦发生与原功能意图不相符的变化，通过跑单元测试可以体现出来，即可以防止功能被无意识地破坏。
* 提高自动化测试占比，降低其他测试方式上的投入。

在经济学中，边际收益递减现象常出现于产量的短期分析中。结合对同事的咨询以及自己的调研，这个现象