单元测试 unit test

单元测试是测试中最常见的也是最基础的一种测试模式，对于前端代码来说，这个“单元"的边界粒度可以是某一个组件或者某一个工具函数；在服务端代码，就可以是针对某一个接口或一个中间件进行测试编写

为什么要写测试？

保证重构时代码的正确性、程序的安全性。 举个例子：某一天需要对原有代码模块进行修改，改完之后不确定是否会对其他模块造成影响，或者破坏原有的逻辑，跑一遍单元测试就能自动地帮助开发者校验代码逻辑的正确性。
帮助开发者完善代码逻辑。 举个例子：在编写一个函数代码的时候，可能开发者只考虑了最基本的情况，并在项目运行时通过了，就主观地认为程序是正确的了。然后在写单元测试，编写测试案例的时候，就得考虑一些边界情况、异常情况等等，这个时候返回去看之前的代码时候，就能发现之前遗漏的一些逻辑并进行完善。

怎么编写单元测试？

• 首先要确定好单元的范围，单元测试必须是针对独立模块的测试
• 编写测试案例(test case)，在我看来测试案例可以分为几种等级：
  • 最基础的案例就是输入一个正确的参数时，能够得到正确的输出；
  • 再升级一点的案例，就是在输入参数导致代码异常时，能够得到处理异常后的结果，而不是让代码错误的结果直接是系统异常而出现；
  • 再再升级一点的话，可以针对极端情况和边界情况进行编写测试案例。
• 代码分支(branch)，代码分支最简单的理解就是代码里的if else，不同的判断条件能够得到不同的输出结果，那么在进行测试编写的时候，不同分支的结果都要覆盖到
• mock数据，单元测试执行过程中，如果遇到一些网络请求、文件I/O等副作用函数，建议使用mock模拟返回数据。最主要的是不能出现因为网络异常的情况，导致测试挂掉了，测试挂掉的情况一定要是代码程序出问题，而不是外界条件出的问题。

哪些代码需要写测试

• 我的观点是：并非所有代码都需要写测试，并且不同模块代码写测试时，所需要的测试案例的等级可以是不同的。
• 核心模块的代码，测试案例等级必须很高，而相对没那么重要或者逻辑并不复杂的模块，可以降低测试案例等级；而一些特殊模块，比如我们暴露给k8s的健康探针(仅仅是一个hello world的简单接口)完全可以不用写测试了。
• 但这些模块优先级，完全是开发人员在针对自己维护的系统，自己来决定了。

测试覆盖率

• 这项指标并不能和项目质量直接挂钩，100%的覆盖率并不能保证你重构代码时完全没问题。
• 要求严格一点的话，可以在CI/CD中可以把覆盖率作为检验指标设置上去，具体阙值可以针对项目交付压力和人员情况做具体调整。
• 不要为了测试覆盖率数据好看，而去写一些意义不大的测试，针对具体情况去写测试

测试框架和工具库

• 顺便再说说我之前用过的一些前端测试框架和工具：
  • jest自带断言库的测试框架，有对应测试typescript代码的ts-jest
  • sinon模拟接口返回
  • mocha一个更容易扩展的测试框架，需要另外单独安装断言库(一般使用chai)

写在最后

• 对技术有追求的人都会觉得写测试是理所当然的，没有任何测试代码的项目绝对不是一个高质量的项目
• 但是写测试的时候也要考虑成本，比如创业项目在需要迅速上线并且开发资源紧张的时候，是否一定要写测试，那也是需要进行权衡的