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

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

写在前面

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


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

如何测试网页的登录页面?

有一个登陆页面, 上面有2个textbox, 一个提交按钮。 请针对这个页面设计30个以上的test case,此题的考察目的: 面试者是否熟悉各种测试方法,是否有丰富的Web测试经验

十大跨浏览器的测试工具

在实际使用中,我们往往会发现某些网站应用虽然能够在Mozilla和Chrome中运行良好,但是在其他浏览器上却总有一些违和感。也许就是因为某个网站的兼容性问题,导致您失去了一个又一个的访客或潜在用户

web自动化测试

对单独的代码块,比如函数进行测试。单元测试是自动化测试的主要形式,也是最基本的形式。集成测试对代码单位之间的协同工作进行测试,比如测试主程序和各个扩展的继承代码。

MyISAM与InnoDB性能测试对比

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

利用chrome_remote_interface实现程序化、自动化Web安全测试

如果要问有哪些抓包神器或者流量分析工具?以下几款工具是必须要提的,burpsuite(跨平台)、fiddler(windows下抓包神器)、wireshark(经典网络抓包工具)、justniffer

Js中for、for...of 、for...in 等 iteration 效率测试

由于不同浏览器,不同版本性能不一,且控制台本质是是套用了一大堆eval,沙盒化程度高,所以需使用node环境测试来提高准确性

js断言测试

断言一词来自逻辑学,在逻辑学中,断言是断定一个特定前提为真的陈述,在软件测试中也是类似的含义。测试中断言语句的一般形式为assert 表达式,其中的表达式就是逻辑学中的陈述

web安全测试必须注意的五个方面

随着互联网的飞速发展,web应用在软件开发中所扮演的角色变得越来越重要,同时,web应用遭受着格外多的安全攻击,其原因在于,现在的网站以及在网站上运行的应用在某种意义上来说,它是所有公司或者组织的虚拟正门

vue-cli3 配置开发-测试环境

首先介绍一下本项目的背景,是基于 vue-cli3.1.1 的单页应用,目前测试环境和生产环境都在线上,并且都在同一个域名下,其中生产环境部署在根目录下,测试环境部署在名为 test 的子目录下,根据生产环境和测试环境的不同

使用Fiddler进行Web接口测试

抓包工具有很多,小到最常用的web调试工具firebug,达到通用的强大的抓包工具wireshark。为什么使用fiddler?原因如下:

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

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

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