前端测试体系和最佳实践

前言

我曾经在好几个项目里都近乎完整参与过补齐前端测试的工作，也收集到不同项目的同事很多关于前端测试的困惑和痛点，这其中大部分都很相似，我也感同身受，在这篇文章里，我会针对大家和自己常遇到的痛点分享一些自己的经验，如果你也有如下相似的困扰，那希望这篇文章能对你有些帮助~

常见问题（排名不分先后）：

• 前端测试感觉写起来很复杂，会花很多时间，甚至经常是业务代码时间的好几倍
• 前端测试怎么TDD？
• 测试一些第三方UI控件时，特别难模拟与之的交互
• 有些东西不知道怎么mock，比如时间，浏览器全局变量（window.location，local storage）等
• 测试里准备数据的代码特别长，真正的测试代码很靠后，要翻很久，不容易定位
• 跑测试时会冒出很多Error或Warn Log，好像不影响测试通过，修起来也很花时间，还用修么？

在分享问题的相关经验之前，我们先来梳理一下前端测试体系~

前端测试体系

前端测试的重要性

这其实跟所有测试的重要性是一样的，大家有这么多的痛点也是因为知道覆盖全面的测试可以对代码质量更有保证，让我们更有信心地去重构代码，也能帮助我们更方便地了解现有的功能细节，甚至是一些极端的边界情况。而且在大家合作开发项目代码的过程中，测试可以帮助我们更早地发现错误，减少时间成本，提高交付效率。

前端测试方法论（TDD vs. BDD）

这两个常见的测试方法论在这里简单介绍一下，就不大篇幅展开了

TDD - (Test-Driven Development 测试驱动开发）简单地说就是先根据需求写测试用例，然后实现代码，通过后再接着写下一个测试和实现，循环直到全部功能和重构完成。基本思路就是通过测试来推动整个开发的进行。

BDD - (Behavior Driven Development 行为驱动开发) 其实可以看做是TDD的一个分支。简单地说就是先从外部定义业务行为，也就是测试用例，然后由外入内的实现这些行为，最后得到的测试用例也是相应业务行为的验收标准。

前端测试的分层

在这里借一下前端大牛Kent C. Dodds的奖杯分层法来引出常见的分类：

（图片出处：https://kentcdodds.com/blog/static-vs-unit-vs-integration-vs-e2e-tests）

端到端测试 End to End Test

端到端测试一般会运行在完整的应用系统上（包括前端和后端），包含用户完整的使用场景，比如打开浏览器，从注册或登录开始，在页面内导航，完成系统提供的功能，最后登出。

有时，我们也会在这里引入可视化用户界面测试，即一种通过像素级比较屏幕截屏来验证页面显示是否正确的测试。目的是确保界面在不同设备、浏览器、分辨率和操作系统下与预期的样式一致。可以设置一定的偏差容忍值。

这一层的测试成本较高，所以通常重心会放在确保主流程的功能正常上。

常用工具：Cypress、Playwright、Puppeteer、TestCafe、Nightwatch （下载量对比）

集成测试 Integration Test

集成测试主要是测试当单元模块组合到一起之后是否功能正常。

在不同的测试上下文下可能有不同的定义，在前端测试这里通常指测试集成多个单元组件到一起的组件。

单元测试 Unit Test

单元测试就是对没有依赖或依赖都被mock掉了的测试单元的测试。在前端代码里，它可能是：

• 没有依赖或依赖都被mock掉了的单元组件
• 功能代码如Utils/Helpers等公共方法集合的测试
• 辅助组件功能如React Hook / Selector等公共方法的测试

静态代码测试 Static Test

主要是指利用一些代码规范工具(Lint Tool)来及时捕获代码中潜在的语句错误，统一代码格式等。这里就不展开了。<