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

　　软件开发要不要写单元测试?想必很多程序员都有这方面的疑问，笔者用几年经验告诉你软件开发过程中值不值得写单元测试?

　　一、不写单元测试的理由

　　工作几年，遇到过不少抗拒写单元测试的人，总结一下大致有以下这么几个理由：

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

　　需求总是无穷尽的，还有下阶段功能需求要实现，没空补单元测试。

　　要补的单元测试太多，无从下手，主观上抗拒。

　　单元测试编写难度大。一方面原因可能是功能函数实现上不够合理，另一方面是没有(或者不知道)好用的单元测试框架和mock框架。

　　单元测试不算入工作量内。

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

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

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

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

　　虽然要为这个问题做精确的投入产出比定量分析比较困难，但并不妨碍我们通过定性分析来得出自己心中的答案。

　　成本(投入)

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

　　收益(产出)

　　提升代码质量。监督开发人员写出更加易于测试和可维护的代码。

　　提升开发团队内部的协作效率。其他开发人员可以通过阅读单元测试用例来理解代码原作者的意图。

　　保证功能实现的长期稳定。代码一旦发生与原功能意图不相符的变化，通过跑单元测试可以体现出来，即可以防止功能被无意识地破坏。

　　提高自动化测试占比，降低其他测试方式上的投入。

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

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

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

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

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

　　横坐标为投入，纵坐标为产出。

　　开始阶段，随着投入的增加，收益(产出)增幅明显，曲线比较陡峭。

　　当投入到达某一临界值，单位投入所获得的收益最大。

　　当投入继续追加并超过临界值，收益的增幅明显放缓，曲线开始变得平缓，单位投入所获得的收益越来越少，即边际收益递减。

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

　　不写单元测试一定不是最佳选择。不写单元测试可以理解为是零投入/零成本，那么必然的也会是零收益。

　　写单元测试并且单元测试的覆盖率接近100%也一定不是最佳选择。由于边际收益递减，投入一旦越过临界值，那么继续追加投入所带来的收益将越来越少。

　　临界值才是理论上的最佳选择。

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

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

　　三、个人的做法

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

　　开源项目一定要写单元测试!开源项目一定要写单元测试!开源项目一定要写单元测试!按照规定，重要的事情得说三遍。除了上文提到的单元测试的好处外，单元测试也是开源项目负责任的一种体现。我花了时间去构思各种情况下的测试用例，我能为开源项目质量负责。

　　不是非得写完一个函数就必须立马写单元测试或者TDD。关于写单元测试的时机，我一般选择在完成一个基本功能后写单元测试，优先覆盖功能的主体逻辑，一些边界条件逻辑不会体现在这个阶段的单元测试当中。我觉得这个阶段也是投入产出比最大的阶段。

　　等功能相对稳定后，再把一些边界条件逻辑纳入到单元测试当中。这是单元测试覆盖率提升较大的阶段。

　　最后一个阶段是刷数据阶段(gbb项目单元测试覆盖率曲线)。所谓的刷数据阶段的主要目标就是为了让覆盖率尽可能提高。刷数据并不是在某个功能成熟稳定后开始，我是选择在开源项目进入成熟阶段后开始刷单元测试覆盖率，为的就是使其更加好看。对于非开源项目，建议选择跳过这个抠细节的阶段。

　　四、参考

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