Jest+Enzyme测试React组件（上）

React函数式组件

fb团队推荐使用函数式组件进行开发，但是函数是无状态的, 用class组件不香嘛，自带state状态，为什么要换写法？原因我们就来讲讲。

 

1. hooks是比HOC和render props更优雅的逻辑复用方式

state是一种外部数据。useState得到的状态，对于组件来说是一种外部传入的数据，和props、context没有本质的区别。useState声明的状态，实际由React内核进行维护，传递给函数式组件。

 

hooks时代的函数式组件依然是【外部数据=>view】的纯函数。

Umi Hooks阿里团队开源的hooks方法集（现已升级为ahooks），可以说是hook界的lodash，足以满足日常开发，复杂业务也可自定义hook。

 

2. 函数式组件的心智模型更加“声明式”

现在hooks直接给你一个声明副作用的API，使得生命周期变成了一个"底层概念"，无需开发考虑，开发者工作在更高的抽象层次上了。

 

3. 纯函数组件对于开启"并发模式"是必备的条件

React渲染过程本质上是在：根据数据模型（应用状态）来计算出视图内容。

组件纯化以后，开发者编写的组件树其实就是 (应用状态)=>DOM结构的纯函数。

又因为应用状态实际由React内核进行维护，所以React内核可以维护多份数据模型，并发渲染多个版本的组件树。

React开发者只需要编写纯函数，不需要关心如何应对这些并发渲染。

等等，不是要说Jest测试嘛？讲了这么多函数式编程是什么鬼?

因为编写单元测试和你的组件划分、逻辑复用、状态传递有很大关系，如果你的编码不规范、代码耦合度高，比如这样：

 

// antd{  title: '状态',  dataIndex: 'optionStatus',  render: (value: number) => (value: number) => {    if (value === 0) {      return <Tag color="red">{PROPOSAL_RULE_ENABLE[0].label}</Tag>    }    if (value === 1) {      return <Tag color="blue">{PROPOSAL_RULE_ENABLE[1].label}</Tag>    }    return <Tag color="blue">{PROPOSAL_RULE_ENABLE[2].label}</Tag>  },  width: 120,},

（左右滑动查看完整代码）

在编写测试语句的时候if条件分支很容易测不全，而且逻辑写在render方法里面，需要在table里mock进去不同的数据，也增加了编码工作。

打个比方：写代码战斗力为80，写单元测试战斗值120+， 首先要明白自己的代码逻辑，才能写出好的测试语句。

而且在开发中要有意识地想到后面的测试怎么写，顾头不顾尾很容易返工改代码，当然，你说我测不全无所谓，一把梭哈干到底？

这样也可以啦，只是后面测试可能会多找你谈谈心......

这就引出了第二个问题：如何根据产品原型划分我的组件， 代码结构怎么设计呢？

 

Testing

 

组件划分

 

React+Typescript+Mobx+hooks。

以上是我所在的部门, 日常开发所采用的技术栈, 举个例子：

按照以上产品原型, 拆分功能模块如下:

函数式组件编码开发:​​​​​​​

Overview   Department.tsx //搜索部门组件   helper.ts //增 删 改 查 变更记录 搜索,方法调用    index.tsx //项目骨架   List.tsx //table表格   SearchForm.tsx //上部搜索组件

（左右滑动查看完整代码）

我们在编写代码的时候，对业务模块进行了充分的拆分，每个功能放在单独的文件中，入口文件没有太重的业务代码。

Department可以放在Component文件夹中，helper文件存放页面的调用方法，以及和store的交互，其余组件只是作为页面UI的渲染。

这里涉及到一个拆分粒度的问题，确保每个文件解决某一单一问题，比如数据格式化可以放在tool文件夹里，页面打散之后，单个文件涉及到的代码逻辑不会太重。

在后续测试中，把文件当作一个个函数，只需要输入不同的参数即可测试。

在这里推荐一个我自己创建的软件测试交流群，QQ：642830685，群中会不定期的分享软件测试资源，测试面试题以及测试行业资讯，大家可以在群中积极交流技术，还有大佬为你答疑解惑。

风里雨里，我在群中等你。