业务代码为什么基本没有单元测试

date

Aug 17, 2022

slug

why-business-code-without-unit-test

status

Published

业务快速迭代是最主要的原因，代码的快速变更让单测用例快速失效。还有就是需求频繁变更的问题。产品今天一个想法，研发开发的过程中，产品又发现逻辑不自洽、交互变更、需求变更，大家应该都遇到过类似的问题，这导致刚刚写完的测试用例又需要变更。

同时业务迭代小步快跑的策略能把人压得喘不上气，无数的需求 + 研发排期的压缩。如果需要在紧迫的排期中（很多业务常年倒排需求，产品定个上线时间点，在这之前必须上线）再挤出时间，说实话真的太难了，这就让写单测这件事情被自动牺牲掉了。

说实话，我感觉这一点是大家能够心安理得不写测试用例的原因。因为 ”开发 → 提测 → 测试环境回归 → 线上环境回归 → 上线“ 的流程，测试起码帮你跑了两遍业务流程，测试说没问题，那么一般来说肯定就不会有问题。

但是对于核心、复杂的业务逻辑，测试同学大概率也是无法帮你回归所有 case 点的，这需要注意。

这个感觉也是时间原因，增加单测就代表了需要维护测试代码，然而又没有那么多时间写…

还有一点就是不是所有研发了解单测，就像我这个菜🐶，进了公司到现在，从来没见过业务代码有人写测试（业务上的工具库大概率也是不写）。

所以怎么样让研发理解单测的意义，然后接受单测，也是个问题。

或者说大家基本都不是很关心代码质量，能 CV（复制粘贴）解决的需求，就 CV 解决… 那还提什么单测了。

测试覆盖率的还不够明显吗？我的代码可维护性提升了呀？但是，业务方会关心这些东西吗？说真的，他们大概率不会 care 这些东西，他们只会关心你的需求明天能不能上线！

我个人理解如果真的重视单测，那么应该是从上至下的推进这个东西，首先业务老板和研发老板对齐认知，我们研发大头兵才有底气去做这件事~

业务代码说全部覆盖测试实话我感觉不太现实 🐶，除非你能解决前面说的几点问题。

现在看下来，研发写单测是一件比较难以推进的事情了，但是我们还有些别的办法曲线救国。

工具库代码最好使用 TDD 的方式进行开发，或者其他测试方案也可以，重要的是保障测试覆盖。因为工具库写测试不是为产品负责、不是为老板负责，而是为自己负责。

测试代码可以让你后面很安心的维护代码，迭代需求。且作为工具库，别人在问你这个库靠不靠谱的时候，你就可以大声的喊出：“我这个测试覆盖率 100% 的，稳的很！”（笑 🤣

对于工具库来说，测试覆盖率真的很重要。如果没有测试代码，你的后续代码变更肯定是举步维艰，自己也会很痛苦，就不要给自己埋坑了。

当我们的业务足够稳定，那么就可以推进对核心的、稳定的业务逻辑代码进行测试用例的编写。

核心的、稳定的，这两点很重要。只要代码够重要，你就必须要写测试。例如一个 BUG 可能导致 N 个 W 的损失的核心业务，你写还是不写？如果不写，那么还敢不敢上线呢？

如果业务流程简单，那么测试同学还可以帮你兜底。但核心业务一般都堆了无数的逻辑上去，测试一般是无法回归到全量 case 的（如果你们的测试足够牛逼，持续整理全量 case，当我没说）。

这其实和前面讲的工具库一个道理，没有测试用例，就不敢动。

我们可以使用前端测试代码覆盖率工具来解决没有测试用例的问题，当然他不会像研发自己写的测试那样靠谱。但是起码保障了一定的稳定行。

前端测试覆盖率工具是指通过代码插装的方式，在测试环境注入运行上报代码。当代码被执行到后，就会进行覆盖率上报。当我们的代码在测试环境被运行到后，这部分代码就为测试通过。未运行到的代码为未覆盖测试。下图（马赛克处理，将就看看）中的红色部分就是测试未覆盖到的代码：

测试覆盖率工具可以帮助我们部分解决代码无测试的尴尬，虽然他也有一定的局限性，那就是运行到所有代码不代表能覆盖所有 case，这就和代码测试覆盖率 100% 一样（测试覆盖率 100% 不代表覆盖 100% 的场景）。

但是，起码它能保障我们的代码都运行到了不是吗 🤣，起码你能够知道测试告诉你我已经测完了的时候，代码到底有没有被测试过~

在测试环境回归代码，不要直接上线，这个就不多说了。