如何对 react hooks 进行单元测试?

时间: 2019-07-13阅读: 564标签: 测试

写在前面

使用 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逻辑上。


站长推荐

1.阿里云: 本站目前使用的是阿里云主机,安全/可靠/稳定。点击领取2000元代金券、了解最新阿里云产品的各种优惠活动点击进入

2.腾讯云: 提供云服务器、云数据库、云存储、视频与CDN、域名等服务。腾讯云各类产品的最新活动,优惠券领取点击进入

3.广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入

链接: http://www.fly63.com/article/detial/4665

使用Jest测试Js

在技​​术术语中测试意味着检查我们的代码是否符合某些预期。例如:给定一些输入,一个名为“transformer”的函数应返回预期的输出。有许多类型的测试,很快你就会被术语所淹没,让我们长话短书。测试分为三大类:

测试代码时你会犯的 11 个错误

我遇到的大多数开发人员都不怎么热衷于测试。有些会去做测试,但大多数都不测试,不愿意测试,或者勉而为之。我喜欢测试,并且比起编写新的代码,愉快地花更多的时间在测试中

10个可靠的Js测试工具

测试JavaScript代码的需求直截了当。如何防止错误,并确保应用程序在浏览器中或Node.js上顺利运行?幸好,开发人员在JavaScript测试方面有很多选择。JavaScript生态系统拥有用于单元测试

MyISAM与InnoDB性能测试对比

MyISAM与InnoDB的优缺点在此就不再多说了,网上可以搜出一堆,而这种文章的最后一般都是推荐,读的多的使用MyISAM,写与更新多的推荐InnoDB,但是,了解过两种存储引擎之后,就会产生一种疑惑,InnoDB采用的是聚簇索引

七种优秀的浏览器兼容性测试工具

在许多谈及网站或Web应用开发的场合,开发人员最为关心的莫过于跨浏览器的兼容性问题。如您所知,诸如:计划、设计、测试等大多数工作都可以在网站的开发阶段顺利完成。但是跨浏览器兼容性问题则会持续到网站上线之后

编写难于测试的代码的5种方式

有一次,我在一个讲座上听到主持人问听众如何故意编写难于测试的代码。在场的小伙伴都惊呆了,因为没有任何人会故意写这种糟糕的代码。我记得他们甚至给不出一个好的答案。

angular如何使用mock?

前后端分离的开发模式中, 为了能让前端不依赖后端服务而能够并行开发, angular-mocks能模拟一些后台返回的数据,从而使前端看起来已经跟后端对接了一样, 只要与后端商定好数据格式, 自己mock一些数据就能够对前端功能进行测试了.

测试工具比较:选Jest,不选Mocha

Jest的未来看起来非常令人激动!看到Jest推陈出新如此快速,我感觉它将很快成为整个React生态系统中大部分项目的首选工具。我建议,应该把测试迁移到Jest上去。

Node.JS中回调嵌套和async/await执行空函数性能效率对比测试

asyn/await关键字可以让原来的回调嵌套和链式写法,改造成同步语法。util.promisify可以很方便地将回调函数Promise化,那么Promise函数的async/await执行和回调函数的嵌套执行或链式执行在性能上有差异吗?

几款Web服务器性能压力测试工具

http_load程序非常小,http_load以并行复用的方式运行,用以测试web服务器的吞吐量与负载。webbench是Linux下的一个网站压力测试工具,最多可以模拟3万个并发连接去测试网站的负载能力。ab是apache自带的一款功能强大的测试工具。安装了apache一般就自带了。

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!

文章投稿关于web前端网站点搜索站长推荐网站地图站长QQ:522607023

小程序专栏: 土味情话心理测试脑筋急转弯幽默笑话段子句子语录成语大全运营推广