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

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

写在前面

使用 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

Macaca自动化测试解决方案

Macaca 是一套面向用户端软件的测试解决方案,提供了自动化驱动,环境配套,周边工具,集成方案,旨在解决终端上的测试、自动化、性能等方面的问题。以及两大平台的混合运行时 Webview,也支持以往的桌面端浏览器。

Vue单元测试

单元测试,就是为了测试某一个类或者是某一个方法能否正常工作而写的测试代码。单元测试是针对 程序的最小单元 来进行正确性检验的测试工作。就是测试某一个页面或者是某一个方法来进行测试的代码单元。

React 现代化测试

测试用例的书写是一个风险驱动的行为, 每当收到 Bug 报告时, 先写一个单元测试来暴露这个 Bug, 在日后的代码提交中, 若该测试用例是通过的, 开发者就能更为自信地确保程序不会再次出现此 bug。

软件测试职业大洗牌

曾经,入行是一件很简单的事。会点点点,是个正常人,愿意做,就行。反正也对你没太大期望,整个软件开发完了,给测试点一遍,没问题,就可以上线了。所以,给很多同学留下的印象就是

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

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

逐点分析,这样做Web端性能测试

71%用户希望在手机上打开网页能跟电脑一样快;5秒钟被认为是用户能忍受的最长响应时间,如果响应时间超过5秒,50%的移动用户会放弃;33%失望的用户会使用竞品替代;

使用Jest测试Js

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

十大跨浏览器的测试工具

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

web自动化测试

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

10个可靠的Js测试工具

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

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

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

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