为什么前端写测试用例困难重重

关于不同测试的种类，网上有很多资料，比如单元、集成、冒烟测试，又比如 TDD BDD 等等，写测试的好处也不用多说，但是就前端来说，写测试用例，特别是针对业务代码测试用例写还是不太常见的事情。我总结的原因有如下几点：

• 
  
• 搭建测试环境比较麻烦，什么 jest config、mock 这个、mock 那个，有那个时间写完 mock，都能写完业务代码了
  
• 网上能找到的测试教程资料都是简单的 demo，与真实业务场景不匹配，看了这些 demo，还是不知道怎么写测试
  
• 网上很难找到合适的模版项目，像 antd 这种都是针对公共 UI 组件的测试用例，对我们写业务逻辑的测试用例没有太大的参考价值
  
• 业务需求改动频繁，导致维护测试用例的成本高
  

我最近在做一个 React Native 项目，想践行 TDD 开发，所以我花了几天时间，梳理了市面上常见的前端测试工具，看了 N 个前端测试实践的文章，最终选择了大道至简，只用下面两个库：

• 
  
• jest，不多说，最流行的类 react 项目的测试框架
  
• react-test-renderer，用于测试组件 UI，搭配 jest 的快照功能一起使用，让测试 UI 变得不再繁琐
  

业务代码的测试用例之心法

不要这样写业务代码的测试用例

不要面向实现写测试用例，比如针对某个组件，把每个 props 都写一个测试用例，而 props 很有可能因为业务改动或重构等原因改动，导致我们也要改动相应的测试用例代码，尽管测试用例本身没有错误。

页面跳转、没有任何交互的静态页面、兼容性、

业务代码要怎么写测试

为了平衡开发时间和写测试用例的时间，我认为对于业务代码来说，测试用例不需要面面俱到，什么逻辑都写个测试用例。我们只需要关注用户交互相关的逻辑，具体来说，我会重点关注以下方面：

• 
  
• pure 组件的 UI 是否有对应的测试用例
  
• 面向功能测试，比如用户输入、点击按钮、加载数据时的 UI、数据为空时的 UI
  
• 针对工具函数的各种输入输出测试
  

写测试用例所需的成本由低到高依次是：

reducer → pure component → business component → DOM testing → e2e

其中 pure component 指的是只有 props 的，只负责渲染的 dummy component。Business compoent 指的是包含 store dispatcher、api fetch、副作用等业务逻辑的业务组件。

程度越靠后，测试的成本越高，所以我们可以花多些精力在测试组件和 reducer 上，少花时间在 DOM 测试和 e2e 测试上。而对于 reducer、pure component、business component 来说，它们的测试用例是相辅相成的，因为 business component 里就包括了 reducer 的使用和 pure component 的渲染，

所以测 business compoent，就等于侧面测到了 reducer 和 pure component。这个测试方法在 Redux 官网也有提到：

完全避免直接测试任何 Redux 代码，将其视为实现细节（cn.redux.js.org/usage/writi…

案例：如何测试 pure component

Dumb Component 只用来接收 props 并进行展示，所以它更易于测试，我们只需要 mock 父组件传来的 props 即可，然后搭配 Jest 的 snapshot 快照来判断测试用例是否通过。

比如我们要测试 Tag Component，这个组件的功能很简单，就是展示标签 UI：

我们可以用快照测试来记录下这个组件的 UI，如果以后 UI 有改动，这条测试用例就会报错。比如我们现在多了一个业务逻辑，需要每个标签都自动带上 []，好比之前标签展示的是 text，根据业务逻辑，现在标签展示的是 [text]。

我们修改 Tag 组件，添加相应的业务逻辑：

这时候跑测试用例，可以发现用例报错，而且我们可以报错结果知道组件的 UI 进行了哪些改动，如果这个改动是符合我们期待的，那么直接更新 snapshot 即可：

同时，提交代码的时候，这条测试用例对应的 snapshot 也会跟着一起 commit，在 Code Review 阶段我们可以根据 snapshot 来直观的看到组件 UI 进行了哪些改动，美滋滋啊。

如何对 Reducer 进行测试

用 Redux 作为状态管理工具时，一种比较好的编程范式是，让 Store 提供数据，组件只负责渲染数据。组件 UI 可能会因为业务变动而频繁的更改，而 Redux 中的数据逻辑不会经常更改，所以在没有任何像上面那种组件 UI 的快照测试时，可以优先测试 Redux，后期补上组件的快照测试。

工作流：

1. 
   
2. 先写测试用例，开一个 snapshot
   
3. 开启 jest --watch，编写 action 和 reducer 相关代码
   
4. 当 snapshot 是我们期待的值，就保存这个 snapshot
   
5. 完成测试用例
   
   作者：Kz
   来源：juejin.cn/post/7253102401452032055
   的编写