让单元测试美如画

废话

我承认，如果没有括号里的那几个字，这个标题看上去有那么点儿欠揍。

前言

我们的网站越来越酷炫，

我们的产品越来越丰富，

我们的团队越来越壮大，

我们的代码越来越复杂，

我们的单测却越来越孱弱？

有没有那么一个功能，看上去棒棒的，让你改又怕怕的？

有没有那么一个class，看起来不知所云，想重构又爱莫能助？

本文主要针对目前单元测试的现状作了一些思考，并尝试提出一些解决方案，希望能让我们的单元测试as pretty as a picture。

现状分析

一句话概括，我们现在的单元测试处于基本停摆的状态。

- 流程上，目前仅有代码（行）覆盖率70%的要求，但实际上也并没有坚决地执行；

- 数量上，虽然盲目地追求代码覆盖率毫无意义，但众多代码模块50%也未到的覆盖率已经说明了问题；

- 质量上，由于缺乏维护，连最基本的100%的成功率都未能达到，质量从何谈起。

相信这种情况在集团内也并不罕见，特别是处于业务极速增长的我们，资源相对更加匮乏，必然会有一些取舍。但这并非所有的原因，可能还有：

* 对单元测试持怀疑态度；

* 对谁来写单元测试有异议；

* 资源紧张，无奈选择“轻流程、重效率”；

* 执行单元测试的流程有问题；

* ......

一般来说，按照先后顺序，或者由小到大，测试分为单元测试、集成测试、系统测试。

而大家应该都认可“越早发现bug造成的损失越小”，那么单元测试作为最早进行的测试无疑有着最高的投入产出比。在单测阶段扼杀bug，将风险控制到最小，将成本减少到最低。

我们有理由将单元测试做得更好：

▪优质的代码不是测出来的，但单元测试的必要性是毋庸置疑的，它是代码落地后的第一道质量防线；

▪单测代码也是代码，是我们产品的一部分，应当主要由开发来编写，我们是最熟悉被测代码的人；

▪代码即产品，由开发和测试共同出品，测试为产品质量保驾护航，应该更多参与单元测试，提供专业的支持；

▪没有质量保障的短期“效率”提升造成的可能是长期的风险、隐患，俗称“坑”；▪ Agile coding, Waterfall testing?

拯救计划

从流程上

如果用一个字形容现在单测在项目中的角色，可能是一个“补”字。

功能代码开发完了，利用提测后的时间来补，往往还不一定能够补全，而如此一来单测的作用就可想而知了。正常情况下，应当新增一个功能，就编写相应的单

测，这是一个迭代的过程，项目的流程类似下图：

如果细看单元测试这一子流程，开发和测试需要更紧密地合作：

(注：真的是没找到不拿茶杯的...)

这样做的好处不言而喻：

# 提高开发测试的并行率，测试前置，风险更可控，提升代码质量，缩短项目周期；

# 提升单测质量，“重单测、轻集成”，提升整体测试效率；

# 互相促进，开发将更具有测试的理念，测试将更加熟悉代码。

从数量上

说到数量，似乎自然而然，也似乎只能联想到测试覆盖率这个颇有争议的衡量标准。难道我们要追求100%的覆盖率吗？If no, then how much?如果这是我们想问的问题，那说明我们已经走进了一个死胡同。

大牛有说过：

任何追求百分百的事物都是值得怀疑的，这就好像写单元测试是为了讨那几个数字欢心，而完全不知道自己在做什么一样。

---- Martin Fowler

那测试覆盖率的价值何在呢？那牛画了幅画：

测试覆盖率应当引导我们发现哪些代码没有被测到，时不时地可以提醒我们：那些代码有bug吗？当然，有可能“有”，也可能“没有”

再回到“数量上”来，既然覆盖率给不了我们答案，又该如何判断多少单元测试才算够呢？没有标准答案，也没有一定之规，需要根据情况，依靠经验来判断。看看那牛有什么建议：

如果做到了以下两点，我觉得你的单元测试足够了：

- 你很少会遗漏bug，直到它到线上才发现

- 你很少因为怕造成线上故障而犹豫该不该改一些代码

那有没有可能too much呢？是的，单元测试会不会太多了？嗯，你猜对了，还是那头牛：

如果你可以去掉一些单测，那说明你的单测太多了。但这很难判断。如果你的单测明显地拖慢了你的节奏，这就是单测太多的一个信号。例如一个简单的代码修改却需要在单测上做很多的修改，这意味着你的单测很可能出了问题。也许并不是你测试了太多东西，而是你的单测中有重复的用例。

另外一个值得参考的做法是，根据风险大小将单元测试分类，并按风险高低决定投入多少（单测用例的多少）

1. 高风险

可能造成重大故障（例如：影响下单主链路、造成资损）、影响大面积用户使用或者已经发现过很多bug或者故障的功能；

2. 低风险

非核心功能且不太可能出bug，即使有bug也不影响使用；

3. 中等风险

介于前两者之间，单一的bug不会影响某一主流程的正常进行

理论上，项目发布前，会看到高风险的单测用例最多或是测试覆盖率最高，中等风险的次之。显然，这里没有一个标准的公式或者模型来自动分类，参考历史数据（故障、bug）和经验积累将作为主要手段，测试（后）、发布（后）的review 将作为有效的补充。

从质量上

Green Bar

成功率100%是一切的基础，运行失败的单元测试只能说明两种情况：

1.被测代码有问题，有bug未被修复；

2.单测代码有问题，已经out of date。

单测设计

单测的目的不是green bar，也不是100%的覆盖率，而是测试。

单测用例的设计决定了单测的质量，是针对条件判定、边界值、robustness或是error guessing，这需要测试同学的专业协助。

规范、约定

其实我们已经有这样的一套规范。这样再补充或强调几点：

一、单元