写在前面

使用 react hook 来做公司的新项目有一段时间了，大大小小的坑踩了不少。由于是公司项目，因此必须要编写单元测试来确保业务逻辑的正确性以及重构时代码的可维护性与稳定性，之前的项目使用的是 react@15.x 的版本，使用 enzyme 配合 jest 来做单元测试毫无压力，但新项目使用的是 react@16.8 ，编写单元测试的时候，遇到不少阻碍，因此总结此篇文章算作心得分享出来。

配合 enzyme 来进行测试

首先，enzyme 对于 hook 的支持程度，可以参考这个 issue，对于各个 hook 的支持程度，里面有链接，有说明，这里就不赘述了。我在这里想说的是，使用 enzyme 来测试 hook 在测试以及验证方式上的一些转变。

测试状态

由于 function component 没有实例的概念，我们无法通过类似 instance.xxx 的方式来直接对状态进行验证，比如：
对于这里的 count 是无法通过 enzyme 中 wrapper.state 的 api 来访问的，但是我们可以通过 wrapper.text 来取出 button 的文字节点，间接地测试 count 状态，如：

const Counter = () => {
 const [count, setCount] = useState(0)
 return <button>{count}</button>
}

测试方法

同理，我们也无法通过 instance.methodXXX 的方式来直接获取组件实例的方法，进而进行调用和测试，比如：

const wrapper = mount(<Counter/>)
expect(wrapper.find('button').text()).toBe('0')

如何获取 inc 方法的引用呢？我们可以通过 wrapper.prop 来曲线救国：

const Counter = () => {
 const [count, setCount] = useState(0)
 const inc = useCallback(() => setCount(c => c + 1), [])
 return <button onClick={inc}>{count}</button>
}

另外，有些情况下，我们以返回值的方式来暴露 hook 中的一些状态以及方法，如果是这样的话，就更简单了，可以通过编写 Wrapper 组件或者直接使用下一小节提及的工具库来进行测试。

使用 @testing-library/react-hooks

测试有返回值的 hook

关于这个工具库，在它的代码仓库中的 README.md 对它要解决的问题、实现原理进行了详细的说明，有兴趣的甚至可以直接看它的源码，十分简单。这里给出一个示例来演示如何测试上一小节最后所说的情况，比如我们有一个 hook:

function useCounter() {
 const [count, setCount] = useState(0)
 const inc = useCallback(() => setCount(c => c + 1), [])
 const dec = useCallback(() => setCount(c => c - 1), [])
 
 return {
  count,
  inc,
  dec
 }
}

首先，我们完全可以通过上一小节的方式来对它进行测试，只需要实现一个临时的 Wrapper，比如：

const CounterIncWrapper = () => {
 const {count, inc} = useCounter()
 return <button onClick={inc}>{count}</button>
}

const CounterDecWrapper = () => {
 const {count, dec} = useCounter()
 return <button onClick={dec}>{count}</button>
}

然后单独按照上一节提及的方式来测试 CounterIncWrapper 或者 CounterDecWrapper 就可以了，但我们会发现，这里的 Wrapper 的逻辑是很相似的，我们是否可以将它抽离为一个公用的逻辑呢？答案当然是可以的，这正是 @testing-library/react-hooks 做的，使用它我们可以这样测试 hook ，如下：

test('should increment counter', () => {
 const { result } = renderHook(() => useCounter())

 act(() => {
  result.current.inc()
 })

 expect(result.current.count).toBe(1)
 
 act(() => {
  result.current.dec()
 })

 expect(result.current.count).toBe(0)
})

这里的 act 是内置的工具方法，可以参考官方文档进行了解，任何对于状态的修改，都应该在它的回调函数中进行，不然会出现错误警告。

测试有依赖项的 hook

有些情况下，我们的 hook 会存在依赖的，比较常见的是 useContext 这个 hook ，它依赖一个 Provider 父组件，比如轻量级的状态管理库 unstated-next ，假设我们将上面的 hook 抽象成了一个独立的 Container (这里会涉及 unstated-next 的 api ，但不影响理解)：

const Counter = createContainer(useCounter)

要使用这个 Container ，我们需要这样：

可以发现，这里的 CounterDisplay 依赖于 Counter.Provider ，要测试 CounterDisplay ，我们通过 renderHook 的 wrapper 参数来注入父组件，比如：

function CounterDisplay() {
 let counter = Counter.useContainer()
 return (
  <div>
   <button onClick={counter.dec}>-</button>
   <span>{counter.count}</span>
   <button onClick={counter.inc}>+</button>
  </div>
 )
}

function App() {
 return (
  <Counter.Provider>
   <CounterDisplay />
  </Counter.Provider>
 )
}

另外， renderHook 还支持 initialProps 参数，它代表回调函数中的参数，这里接不赘述了。

测试副作用

hook 中比较难搞的应该算是 useEffect ，我花了很长时间来看别人是如何对它进行单元测试的，但是并没有得到一些有用的信息，后来我仔细想了想，其实这个问题应该这样来想， useEffect 是用来封装副作用的，它只用来负责副作用的运行时机，对于副作用干了什么，对于 useEffect 完全是透明的。因此我们没有必要对它进行单元测试，而应该在副作用的实现层确保它的正确性。但我们通常会将副作用的实现与 hook 的实现耦合起来，那怎么对副作用的实现进行测试呢？这里可以分两种情况。

useEffect 会运行 props 中传递的回调函数

这种情况相对简单一些，只需要通过 jest.fn() 来构造一个 spy 函数，之后通过上一节的方式渲染 hook ，通过 jest 对于 spy 函数的 api 来进行验证即可。

useEffect 自成一体

这种情况下，我当前是通过将副作用代码，直接声明在 hook 外部的方式来进行测试的，比如：

export function updateDocumentTitle(title) {
 document.title = title
 
 return () => {
   document.title = 'default title'
 }
}

export function useDocumentTitle(title) {
 useEffect(() => updateDocumentTitle(title), [title])
}

这样，只需要单独测试 updateDocumentTitle 就好，而不需要在 useEffect 上花费功夫了。

这里可能有的人会问，你这里无法覆盖 title 改变时， effect 是否重新运行的场景，确实，当前我也没有办法解决这种问题，如果要解决，办法还是有的，就是通过 useDocumentTitle 的参数，来传递 updateDocumentTitle ，但这对于代码有很强的侵入性，我不建议这样做，如果 hook 本身的实现方式就是这样，那完全可以针对它编写相关的测试用例，如果不是，也没有必要为了写测试用例而改写原来的实现。

hook 无法被测试的原因

在对公司项目各个 hook 编写单元测试时，发现一些 hook 非常难以测试，大体的特征如下：

• hook 的实现非常复杂，状态繁多，依赖繁多
• hook 的实现不复杂，但外部依赖难以 mock
• hook 的实现自成一体，没有入口

关于第一点，解决的方法当然是，化繁为简，将复杂的 hook，划分为多个简单的 hook，使其职责更单一。对于第二点，如果外部依赖难以 mock ，我建议将它的测试用例放到集成测试阶段进行实现，而不要花费过多精力在编写单元测试的 mock 逻辑上。最后一点的解决方法详见上一小节。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。