你真的需要单元测试吗?

博主最近在接触一些Android单元测试方面的工作，发现自己并没有体会到大多数文章所宣传的“单元测试会带来工作效率的巨大提升”之类的诸多好处，于是本着批判与自我批判的精神对单元测试做了一番研究，以下言论仅代表个人观点，如果不足，欢迎指教。

单元测试不是用来找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）：

成本(投入)

• 编写单元测试用例所额外付出的时间，短期内会拖慢项目进度。

收益(产出)

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

在经济学中，边际收益递减现象常出现于产量的短期分析中。结合对同事的咨询以及自己的调研，这个现象在软件开发领域同样适用。当我们需要写原型或者开发一个短期紧急需求的时候，（产品、运营人员）往往要求快速交付，并且由于代码规模有限也往往不会有太多Bug，在这种短期开发中如果引入单元测试往往会适得其反，投入了双倍的时间却没有明显的附加收益。而分析How Google Tests Software一书中最多提及的几个项目（Chrome,Android,Gmail）可以发现，单元测试（更准确说是Test-Driven Development）的成功案例往往都是一些架构设计良好，处于长期迭代开发，基本没有短期临时紧急需求的产品，项目初期的单元测试往往在几年后还能使用，复用率极高（私以为复用率某种程度上可以作为是否值得引入单元测试的标准）。而如果一个项目一开始没有引入单元测试、过时和糟糕的代码没有及时重构、临时短期需求偏多，往往就没有引入单元测试的必要了。

Jake Wharton也头疼的单元测试

Jake Wharton何许人也?答：诸多著名开源项目的作者，Android社区的旗帜人物：
[图片上传失败...(image-547317-1523347911909)]
Jake Wharton对于Android平台的单元测试也十分头痛（Against Android Unit Tests

原文转自：https://www.jianshu.com/p/1980c944e31c