如何对 react hooks 进行单元测试

2019-08-13

写在前面

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

配合 enzyme来进行测试

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

测试状态

由于 function component没有实例的概念,我们无法通过类似 instance.xxx的方式来直接对状态进行验证,比如: 对于这里的 count是无法通过 enzymewrapper.stateapi来访问的,但是我们可以通过 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组件或者直接使用下一小节提及的工具库来进行测试。

测试有返回值的 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-nextapi,但不影响理解):

const Counter = createContainer(useCounter)

要使用这个 Container,我们需要这样: 可以发现,这里的 CounterDisplay依赖于 Counter.Provider,要测试 CounterDisplay,我们通过 renderHookwrapper参数来注入父组件,比如:

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逻辑上。最后一点的解决方法详见上一小节。

写在最后

本身纯属个人观点,如有错误,还望指正。


关注公众号,全栈_101,只谈技术,不谈人生。

clipboard.png


另:本人最近比较缺钱,业余时间接手各种规模的外包项目:

  • 前端 react/vue/angular及性能优化
  • 后端 java/python

有意者私聊。

原文链接:segmentfault.com

上一篇:已购买极客时间前端课程
下一篇:前端开发常见笔试/面试题总结 -- HTML / CSS篇
相关教程
关注微信

扫码加入 JavaScript 社区

相关文章

首次访问,需要验证
微信扫码,关注即可
(仅需验证一次)

欢迎加入 JavaScript 社区

号内回复关键字:

回到顶部