如何对react hooks进行单元测试的方法
写在前面
使用reacthook来做公司的新项目有一段时间了，大大小小的坑踩了不少。由于是公司项目，因此必须要编写单元测试来确保业务逻辑的正确性以及重构时代码的可维护性与稳定性，之前的项目使用的是react@15.x的版本，使用enzyme配合jest来做单元测试毫无压力，但新项目使用的是react@16.8，编写单元测试的时候，遇到不少阻碍，因此总结此篇文章算作心得分享出来。
配合enzyme来进行测试
首先，enzyme对于hook的支持程度，可以参考这个issue，对于各个hook的支持程度，里面有链接，有说明，这里就不赘述了。我在这里想说的是，使用enzyme来测试hook在测试以及验证方式上的一些转变。
测试状态
由于functioncomponent没有实例的概念，我们无法通过类似instance.xxx的方式来直接对状态进行验证，比如：
对于这里的count是无法通过enzyme中wrapper.state的api来访问的，但是我们可以通过wrapper.text来取出button的文字节点，间接地测试count状态，如：
constCounter=()=>{
const[count,setCount]=useState(0)
return
}
测试方法
同理，我们也无法通过instance.methodXXX的方式来直接获取组件实例的方法，进而进行调用和测试，比如：
constwrapper=mount() expect(wrapper.find('button').text()).toBe('0')
如何获取inc方法的引用呢？我们可以通过wrapper.prop来曲线救国：
constCounter=()=>{
const[count,setCount]=useState(0)
constinc=useCallback(()=>setCount(c=>c+1),[])
return{count}
}
另外，有些情况下，我们以返回值的方式来暴露hook中的一些状态以及方法，如果是这样的话，就更简单了，可以通过编写Wrapper组件或者直接使用下一小节提及的工具库来进行测试。
使用@testing-library/react-hooks
测试有返回值的hook
关于这个工具库，在它的代码仓库中的README.md对它要解决的问题、实现原理进行了详细的说明，有兴趣的甚至可以直接看它的源码，十分简单。这里给出一个示例来演示如何测试上一小节最后所说的情况，比如我们有一个hook:
functionuseCounter(){
const[count,setCount]=useState(0)
constinc=useCallback(()=>setCount(c=>c+1),[])
constdec=useCallback(()=>setCount(c=>c-1),[])
return{
count,
inc,
dec
}
}
首先，我们完全可以通过上一小节的方式来对它进行测试，只需要实现一个临时的Wrapper，比如：
constCounterIncWrapper=()=>{
const{count,inc}=useCounter()
return{count}
}
constCounterDecWrapper=()=>{
const{count,dec}=useCounter()
return{count}
}
然后单独按照上一节提及的方式来测试CounterIncWrapper或者CounterDecWrapper就可以了，但我们会发现，这里的Wrapper的逻辑是很相似的，我们是否可以将它抽离为一个公用的逻辑呢？答案当然是可以的，这正是@testing-library/react-hooks做的，使用它我们可以这样测试hook，如下：
test('shouldincrementcounter',()=>{
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，但不影响理解)：
constCounter=createContainer(useCounter)
要使用这个Container，我们需要这样：
可以发现，这里的CounterDisplay依赖于Counter.Provider，要测试CounterDisplay，我们通过renderHook的wrapper参数来注入父组件，比如：
functionCounterDisplay(){
letcounter=Counter.useContainer()
return(
-
{counter.count}
+
)
}
functionApp(){
return(
)
}
另外，renderHook还支持initialProps参数，它代表回调函数中的参数，这里接不赘述了。
测试副作用
hook中比较难搞的应该算是useEffect，我花了很长时间来看别人是如何对它进行单元测试的，但是并没有得到一些有用的信息，后来我仔细想了想，其实这个问题应该这样来想，useEffect是用来封装副作用的，它只用来负责副作用的运行时机，对于副作用干了什么，对于useEffect完全是透明的。因此我们没有必要对它进行单元测试，而应该在副作用的实现层确保它的正确性。但我们通常会将副作用的实现与hook的实现耦合起来，那怎么对副作用的实现进行测试呢？这里可以分两种情况。
useEffect会运行props中传递的回调函数
这种情况相对简单一些，只需要通过jest.fn()来构造一个spy函数，之后通过上一节的方式渲染hook，通过jest对于spy函数的api来进行验证即可。
useEffect自成一体
这种情况下，我当前是通过将副作用代码，直接声明在hook外部的方式来进行测试的，比如：
exportfunctionupdateDocumentTitle(title){
document.title=title
return()=>{
document.title='defaulttitle'
}
}
exportfunctionuseDocumentTitle(title){
useEffect(()=>updateDocumentTitle(title),[title])
}
这样，只需要单独测试updateDocumentTitle就好，而不需要在useEffect上花费功夫了。
这里可能有的人会问，你这里无法覆盖title改变时，effect是否重新运行的场景，确实，当前我也没有办法解决这种问题，如果要解决，办法还是有的，就是通过useDocumentTitle的参数，来传递updateDocumentTitle，但这对于代码有很强的侵入性，我不建议这样做，如果hook本身的实现方式就是这样，那完全可以针对它编写相关的测试用例，如果不是，也没有必要为了写测试用例而改写原来的实现。
hook无法被测试的原因
在对公司项目各个hook编写单元测试时，发现一些hook非常难以测试，大体的特征如下：
- hook的实现非常复杂，状态繁多，依赖繁多
- hook的实现不复杂，但外部依赖难以mock
- hook的实现自成一体，没有入口
关于第一点，解决的方法当然是，化繁为简，将复杂的hook，划分为多个简单的hook，使其职责更单一。对于第二点，如果外部依赖难以mock，我建议将它的测试用例放到集成测试阶段进行实现，而不要花费过多精力在编写单元测试的mock逻辑上。最后一点的解决方法详见上一小节。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持毛票票。