软件开发过程当中值不值得写单元测试？

原文连接: https://voidint.github.io/pos...

1、不写单元测试的理由

工做几年，遇到过很多抗拒写单元测试的人，总结一下大体有如下这么几个理由：

首先，写单元测试所支出的时间可能比实现功能自己所花费的时间还多。言外之意，在实现完全部功能以前不值得写单元测试。若是现阶段功能开发大体完毕，可能也不会去补上亏欠的单元测试，理由大体有这么几点：

• 需求老是无穷尽的，还有下阶段功能需求要实现，没空补单元测试。
• 要补的单元测试太多，无从下手，主观上抗拒。
• 单元测试编写难度大。一方面缘由多是功能函数实现上不够合理，另外一方面是没有(或者不知道)好用的单元测试框架和mock框架。
• 单元测试不算入工做量内。

其次，功能需求还不稳定，写单元测试的性价比不高。换句话说，万一明天需求一变，那不光功能代码废了，单元测试也废了。若是不写单元测试，那这部分工夫就不会白费。

2、写单元测试的投入产出比

以投入产出比做为这个问题的判断依据，我以为是全部理性人都会作出的选择。而既然引入了投入产出比这个经济学上的概念，那么应该也能接受另外一个经济学上的普世规律——边际收益递减。以及资源(主要指时间和精力)具备稀缺性这一规律。

下面的分析都将是创建在以上这些共识的基础之上，若是你并不认同这些规律一样能够用来分析软件开发过程当中值不值得写单元测试这个问题，那么阅读如下内容仅仅是在浪费你宝贵的时间。若是你继续往下阅读，那么，我将假设你已经和我达成了这些共识。

虽然要为这个问题作精确的投入产出比定量分析比较困难，但并不妨碍咱们经过定性分析来得出本身心中的答案。

成本(投入)

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

收益(产出)

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

从上面我所罗列的成本/收益数量上说，收益的数量远大于成本。可是，分析投入产出比并非掰手指数数量就能得出答案的，特此说明。

首先，短时间项目不写单元测试是划算的选择。至于到底多长时间算做短时间，并没有定论。我选择将一个月做为划分的界限，一月之内为短时间，多于一月是中期或者长期，至于中长期的界限在哪儿，这个可有可无，暂且不论。

短时间项目的典型表明就是演示用demo项目。这类项目的共性是时间紧迫，项目生命周期短，无需后续的维护，使用一次性(或者接近一次性)。若是说中长期项目的使用周期(区别于开发周期)是时间段的话，那么短时间项目的使用周期就是一个时间点或者几个时间点。这种状况下将有限的资源投入到单元测试中，所得到的收益并不明显。若是继续追加投入，因为收益增幅平缓，投入产出比极低，甚至为负。索性零投入零产出，虽然略显保守，但也不失为一个好的选择。

其次，中长期项目不写单元测试绝对不是划算的选择。请注意，这里我并无说中长期项目写单元测试是划算的选择这样的话。由于写单元测试这个说法太宽泛。很明显，单元测试覆盖率1%与99%是有巨大区别的，而这二者都属于写单元测试这个范畴。

对于中长期项目，将资源投入到单元测试上所得到的收益曲线会是这样(不太会画图，暂且用文字描述)：

• 横坐标为投入，纵坐标为产出。
• 开始阶段，随着投入的增长，收益(产出)增幅明显，曲线比较陡峭。
• 当投入到达某一临界值，单位投入所得到的收益最大。
• 当投入继续追加并超过临界值，收益的增幅明显放缓，曲线开始变得平缓，单位投入所得到的收益愈来愈少，即边际收益递减。

若是你也承认以上的投入产出比曲线，那么不难推出如下几个结论：

• 不写单元测试必定不是最佳选择。不写单元测试能够理解为是零投入/零成本，那么必然的也会是零收益。
• 写单元测试而且单元测试的覆盖率接近100%也必定不是最佳选择。因为边际收益递减，投入一旦越过临界值，那么继续追加投入所带来的收益将愈来愈少。
• 临界值才是理论上的最佳选择。

上面提到的临界值是属于写单元测试的范畴，而且单元测试覆盖率在0%~100%之间的某个点。因此说，软件开发过程当中值不值得写单元测试这个问题的答案应该无需再多言了。

文章一开始提到的那些不写单元测试的理由，每每是抱着一个非黑即白的观点，认为不写单元测试的反面就是写单元测试且覆盖率近100%。于是会过度夸大写单元测试的成本(单元覆盖率100%的代价固然大)，选择短时间利益。

3、我的的作法

下面以我的的小开源项目gbb为例，啰嗦几句我本身写单元测试的习惯。

• 开源项目必定要写单元测试！开源项目必定要写单元测试！开源项目必定要写单元测试！按照规定，重要的事情得说三遍。除了上文提到的单元测试的好处外，单元测试也是开源项目负责任的一种体现。我花了时间去构思各类状况下的测试用例，我能为开源项目质量负责。
• 不是非得写完一个函数就必须立马写单元测试或者TDD。关于写单元测试的时机，我通常选择在完成一个基本功能后写单元测试，优先覆盖功能的主体逻辑，一些边界条件逻辑不会体如今这个阶段的单元测试当中。我以为这个阶段也是投入产出比最大的阶段。
• 等功能相对稳定后，再把一些边界条件逻辑归入到单元测试当中。这是单元测试覆盖率提高较大的阶段。
• 最后一个阶段是刷数据阶段(gbb项目单元测试覆盖率曲线)。所谓的刷数据阶段的主要目标就是为了让覆盖率尽量提升。刷数据并非在某个功能成熟稳定后开始，我是选择在开源项目进入成熟阶段后开始刷单元测试覆盖率，为的就是使其更加好看。对于非开源项目，建议选择跳过这个抠细节的阶段。

4、参考

在写这篇博客时，我并无查阅相关的这类文章。为的就是防止他人的观点在不知不觉中掺入其中，影响了个人原始观点。