单元测试的故事

就只是想讲一些故事。

背景

项目的全部后端代码有单元测试覆盖率的tolerance，现在是96.47%。
同时我们有一个Attribute [皇马甲]，只要给代码穿上它，覆盖率统计工具就会开绿灯，不会纳入统计范围。是的，96.47%呵呵了。

我们项目是基于一个第三方的基础框架来进行上层建筑的构建，因为依赖于基础架构，所以很多代码实现上的问题我们身不由己。单元测试UT便是其中之一。凡是跟基础框架有关的代码，写单元测试的时候主要有两个痛点。第一，涉及框架的调用与我们自己实现的业务代码有继承关系，单元测试不好区分隔离，所以为了单元测试必须额外动手做一些提取抽象的动作。第二，框架中的model是一个复杂结构的对象，很多单元测试需要构建整个对象来完成数据准备，但其实业务逻辑只需要其中很小的一部分，这就造成了单元测试的过程复杂，效率低。从大家的反馈看，第二点更痛一些。

可是，经过了estimation的每一张卡，是包括了单元测试工作量的。

故事1

Feature I 非常重要，时间紧迫。
Team 1 同学们压力很大，十分辛苦。最终仍然按时交付了。
可是后来我们发现，Feature I的代码中存在皇马甲，还包括[皇马甲("Dev A")]这种。可是，交付之后Team 1就解散了，分散到其他Feature上。Dev A，因为其他原因离职了。
现在皇马甲还穿着。

故事2

Dev B 是一位为项目奉献巨大的同学。也是因为交付时间紧迫，也套上了[皇马甲("Dev B")]。
在听闻Dev B要roll off的时候，同学们就多次提醒，不要重现Dev A的事故，人走了，皇马甲还在。
然后在Dev B roll off的当天party上，他说皇马甲就留下吧，“来过，奋斗过”。大家笑，现场气氛和谐融融。

故事3

Dev C 是一位研学大师，建树不限于微服务和DDD。不同与A与B，他还在为项目奉献着。
但是他对痛点二深恶痛绝，曾言，“在这样的情况下写出的UT，没有意义，不可读，不可维护，纯粹是浪费时间。你们看，我给你们找找别人是怎么做UT的，你看这样的UT就很清晰，数据准备简单，Assert清晰....”
所以C偶尔会使用皇马甲技术来提高工作效率。

故事4

Dev D 是在其他项目结束了之后onboard到我们项目上的，我们项目的业务确实复杂，要花时间弄懂很多业务知识。
所以他开始的几张卡，交付周期都比估点的时间要长，身为新人，压力就会很大。所以为了减少交卡的时间，他选择先使用皇马甲技术，等休假的时候再额外花时间补UT。

....

是的，以上几位理由都成立。你猜，我们在一家什么样的公司，你猜，他们几位分别是什么职级。

客户以为交付的feature是有UT cover的，是有保障的。
客户以为安排的工作量是合适的，team不会觉得压力太大，大家都只需要每天8小时就好。
同学以为自己的单元测试逻辑覆盖有问题，因为pull了最新代码，覆盖率居然降低了。
同学以为pull rebase之后就可以交代码了，结果覆盖率低过tolerance，被Block了。
QA以为在拿到卡的时候，UT已经run过了，基本保障是有的。
SM以为每个迭代统计的数据是真实的，估的点数映射到人·天是没毛病的。

我以为我们的目标是一致的，是一个team，责任一起扛。现在的感觉特别像当年上大学的时候住寝室，卫生只有我打扫，厕所只有我去刷。

有个不方便透漏名字的人说过，我们都不是这家公司的好职员，我们都在干着脏活累活。