单元测试

Mr.Hope2024年11月11日大约 4 分钟

提示

外企工作的两年里，工作的硬性指标之一就是 jest 单元测试覆盖率必须 80%以上，但所谓的"80%"真的有意义吗?

什么是单元

再开始编写单元测试脚本之前，我们需要知道单元测试存在的意义是什么

在理解单元测试的意义前，我们首先要理解什么叫做单元

所谓单元，你可以用流水线中的零件去类别，我们的程序就像一条流水线，由各种各样的零件去组成，也正如一个页面，是由各种各样的模块去组成一样

因此单元，具体到代码世界，泛指的就是那些无状态的组件，纯函数，hook，或是职责单一的模块

而绝不是指代那些由各种各样上述提到的单元组成的大的程序 所以很多同学用jest为页面编写测试脚本，从出发点上就是错的

提示

所有"单元"，均是为了稳定地服务那些依赖它的程序

正如上述Tips所说，所有"单元"，均是为了稳定地服务那些依赖它的程序，这里我强调了稳定二字

想象一个场景，一个银行支付流程，该流程需要极高的稳定性，但该流程相当复杂，它是由非常多的各种各样的单元去组成，因此在要求该流程稳定的同时，其实也是在要求它依赖的单元去保证稳定

但我们要如何保证"单元"的稳定呢?

答案就是: "单元测试"

假设上述支付流程上依赖的某一个单元，并假设该单元会遇到以下两种情形

毫无疑问，升级和重构对单元来说是一件好事，随着业务发展也是必须要的事

但对依赖了这个单元的流程来说算不上一件好事，因为每次代码的改动，都会引发出很多潜在风险

而任何风险对稳定性要求极高的系统来说，都是一种极大的挑战

这个时候，我们就需要测试去保证单元功能的稳定,

像我以前的解决方案，就是在重构或升级该单元之前，为该单元编写一个完整的单元测试

在编写完测试用例之后，我会先跑一遍测试用例脚本，直到该脚本的测试结果如我所愿，再开始着手重构或升级该单元

重构或升级完毕之后，我会再跑一次原有的测试用例，如果一切顺利，该脚本的测试结果也应该是如我所愿，这种情况下，本次重构或升级才算的上是及格

如果测试结果不如我所愿呢，那也属于是正常的范畴，毕竟改动就会有风险

这种情况下，我们也可以根据测试结果的反馈，快速定位问题，修复问题，直到测试结果符合心理预期为止

提示

如果是升级阶段，我们记得要为其补充上针对新功能的测试用例

提示

还有一个值得注意的点就是~ 在升级和重构的场景，测试用例脚本必须是在升级和重构前编写，因为这个脚本的目的，是为了保证原有功能的稳定，如果你在升级和重构后编写，即使最后脚本的覆盖率是百分之百，我们也没有办法确认这个单元原有的功能是不受影响的