React 单元测试策略及落地

写好的单元测试，对开发速度、项目维护有莫大的帮助。前端的测试工具一直推陈出新，而测试的核心、原则却少有变化。与产品代码一并交付可靠的测试代码，是每个专业开发者应该不断靠近的一个理想之地。本文就围绕测试讲讲，为什么我们要做测试，什么是好的测试和原则，以及如何在一个 React 项目中落地这些测试策略。

本文使用的测试框架、断言工具是 jest。文章不打算对测试框架、语法本身做过多介绍，因为已有很多文章。本文假定读者已有一定基础，至少熟悉语法，但并不假设读者写过单元测试。在介绍什么是好的单元测试时，我会简单介绍一个好的单元测试的结构。

• 为什么要做单元测试

• • 有且仅有一个失败的理由

  • 表达力极强

  • 快、稳定

  • 单元测试的上下文

  • 测试策略：测试金字塔

  • 如何写好单元测试：好测试的特征

• React 单元测试策略及落地

• • 业务型组件 - 分支渲染

  • 业务型组件 - 事件调用

  • 功能型组件 - children 型高阶组件

  • 来自官方的错误姿势

  • 正确姿势

  • React 应用的单元测试策略

  • actions 测试

  • reducer 测试

  • selector 测试

  • saga 测试

  • component 测试

  • utils 测试

• 总结

为什么要做单元测试

虽然关于测试的文章有很多，关于 React 的文章也有很多，但关于 React 应用之详细单元测试的文章还比较少。而且更多的文章都更偏向于对工具本身进行讲解，只讲「我们可以这么测」，却没有回答「我们为什么要这么测」、「这么测究竟好不好」的问题。这几个问题上的空白，难免使人得出测试无用、测试成本高、测试使开发变慢的错误观点，导致在「质量内建」已渐入人心的今日，很多人仍然认为测试是二等公民，是成本，是锦上添花。这一点上，我的态度一贯鲜明：不仅要写测试，还要把单元测试写好；不仅要有测试前移质量内建的意识，还要有基于测试进行快速反馈快速开发的能力。没自动化测试的代码不叫完成，不能验收。

「为什么我们需要做单元测试」，这是一个关键的问题。每个人都有自己关于该不该做测试、该怎么做、做到什么程度的看法，试图面面俱到、左右逢源地评价这些看法是不可能的。我们需要一个视角，一个谈论单元测试的上下文。做单元测试当然有好处，但本文不会从有什么好处出发来谈，而是谈，在我们在意的这个上下文中，不做单元测试会有什么问题。

那么我们谈论单元测试的上下文是什么呢？不做单元测试我们会遇到什么问题呢？

单元测试的上下文

先说说问题。最大的一个问题是，不写单元测试，你就不敢重构，就只能看着代码腐化。代码质量谈不上，持续改进谈不上，个人成长更谈不上。始终是原始的劳作方式。

再说说上下文。我认为单元测试的上下文存在于「敏捷」中。现代企业数字化竞争日益激烈，业务端快速上线、快速验证、快速失败的思路对技术端的响应力提出了更高的要求：更快上线、更频繁上线、持续上线。怎么样衡量这个「更快」呢？那就是第一图提到的 lead time，它度量的是一个 idea 从提出并被验证，到最终上生产环境面对用户获取反馈的时间。显然，这个时间越短，软件就能越快获得反馈，对价值的验证就越快发生。这个结论对我们写不写单元测试有什么影响呢？答案是，不写单元测试，你就快不起来。为啥呢？因为每次发布，你都要投入人力来进行手工测试；因为没有测试，你倾向于不敢随意重构，这又导致代码逐渐腐化，复杂度使得你的开发速度降低。

再考虑到以下两个大事实：人员会流动，应用会变大。人员一定会流动，需求一定会增加，再也没有任何人能够了解任何一个应用场景。因此，意图依赖人、依赖手工的方式来应对响应力的挑战首先是低效的，从时间维度上来讲也是不现实的。那么，为了服务于「高响应力」这个目标，我们就需要一套自动化的测试套件，它能帮我们提供快速反馈、做质量的守卫者。唯解决了人工、质量的这一环，效率才能稳步提升，团队和企业的高响应力才可能达到。

那么在「响应力」这个上下文中来谈要不要单元测试，我们就可以很有根据了，而不是开发爽了就用，不爽就不用这样含糊的答案：

• 如果你说我的业务部门不需要频繁上线，并且我有足够的人力来覆盖手工测试，那你可以不用单元测试

• 如果你说我是个小项目小部门不需要多高的响应力，每天摸摸鱼就过去了，那你可以不用单元测试

• 如果你说我不在意代码腐化，并且我也不做重构，那你可以不用单元测试

• 如果你说我不在意代码质量，好几个没有测试保护的 if-else 裸奔也不在话下，脑不好还做什么程序员，那你可以不用单元测试

• 如果你说我确有快速部署的需求，但我们不 care 质量问题，出回归问题就修，那你可以不用单元测试 除此之外，你就需要写单元测试。如果你想随时整理重构代码，那么你需要写单元测试；如果你想有自动化的测试套件来帮你快速验证提交的完整性，那么你需要写单元测试；如果你是个长期项目有人员流动，那么你需要写单元测试；如果你不想花大量的时间在记住业务场景和手动测试应用上，那么你就需要单元测试。

至此，我们从「响应力」这个上下文中，回答了「为什么我们需要写单元测试」的问题。接下来可以谈下一个问题了：「为什么是单元测试」。

测试策略：测试金字塔

上面我直接从高响应力谈到单元测试，可能有的同学会问，高响应力这个事情我认可，也认可快速开发的同时，质量也很重要。但是，为了达到「保障质量」的目的，不一定得通过测试呀，也不一定得通过单元测试鸭。

这是个好的问题。为了达到保障质量这个目标，测试当然只是其中一个方式，稳定的自动化部署、集成流水线、良好的代码架构、组织架构的必要调整等，都是必须跟上的设施。我从未认为单元测试是解决质量问题的银弹，多方共同提升才可能起到效果。但相反，也很难想象单元测试都没有都写不好的项目，能有多高的响应力。

即便我们谈自动化测试，未必也不可能全部都是写单元测试。我们对自动化测试套件寄予的厚望是，它能帮我们安全重构已有代码、保存业务上下文、快速回归。测试种类多种多样，为什么我要重点谈单元测试呢？因为~~这篇文章主题就是谈单元测试啊…~~它写起来相对最容易、运行速度最快、反馈效果又最直接。下面这个图，想必大家都有所耳闻：

这就是有名的测试金字塔。对于一个自动化测试套件，应该包含种类不同、关注点不同的测试，比如关注单元的单元测试、关注集成和契约的集成测试和契约测试、关注业务验收点的端到端测试等。正常来说，我们会受到资源的限制，无法应用所有层级的测试，效果也未必最佳。因此，我们需要有策略性地根据收益-成本的原则，考虑项目的实际情况和痛点来定制测试策略：比如三方依赖多的项目可以多写些契约测试，业务场景多、复杂或经常回归的场景可以多写些端到端测试，等。但不论如何，整个测试金字塔体系中，你还是应该拥有更多低层次的单元测试，因为它们成本相对最低，运行速度最快（通常是毫秒级别），而对单元的保护价值相对更大。

以上是对「为什么我们需要的是单元测试」这个问题的回答。接下来一小节，就可以正式进入如何做的环节了：「如何写好单元测试」。

关于测试金字塔的补充阅读：测试金字塔实战。

如何写好单元测试：好测试的特征

写单元测试仅仅是第一步，下面还有个更关键的问题，就是怎样写出好的、容易维护的单元测试。好的测试有其特征，虽然它并不是什么新的东西，但总需要时时拿出来温故知新。很多时候，同学感觉测试难写、难维护、不稳定、价值不大等，可能都是因为单元测试写不好所导致的。那么我们就来看看，一个好的单元测试，应该遵循哪几点原则。

首先，我们先来看个简单的例子，一个最简单的 JavaScript 的单元测试长什么样：

// production code
const computeSumFromObject = (a, b) => {
  return a.value + b.value
}

// testing code
it('should return 5 when adding object a with value 2 and b with value 3', () => {
  // given - 准备数据
  const a = { value: 2 }
  const b = { value: 3 }

  // when - 调用被测函数
  const result = computeSumFromObject(a, b)

  // then - 断言结果
  expect(result).toBe(5)
})

以上就是一个最简答的单元测试部分。但麻雀虽小，五脏基本全，它揭示了单元测试的一个基本结构：准备输入数据、调用被测函数、断言输出结果。任何单元测试都可以遵循这样一个骨架，它是我们常说的 given-when-then 三段式。

为什么说单元测试说来简单，做到却不简单呢？除了遵循三段式，显然我们还需要遵循一些其他的原则。前面说到，我们对单元测试寄予了几点厚望，下面就来看看，它如何能达到我们期望的效果，以此来反推单元测试的特征：

• 安全重构已有代码 -> 应该有且仅有一个失败的理由、不关注内部实现

• 保存业务上下文 -> 表达力极强

• 快速回归 -> 快、稳定

下面来看看这三个原则都是咋回事：

有且仅有一个失败的理由

有且仅有一个失败的理由，这个理由是什么呢？是 「当输入不变时，当且仅当被测业务代码功能被改动了」时，测试才应该挂掉。为什么这会支持我们重构呢，因为重构的意思是，在不改动软件外部可观测行为的基础上，调整软件内部实现的一种手段。也就是说，当我被测的代码输入输出没变时，任我怎么倒腾重构代码的内部实现，测试都不应该挂掉。这样才能说是支持了重构。有的单元测试写得，内部实现（比如数据结构）一调整，测试就挂掉，尽管它的业务本身并没修改，这样怎么支持重构呢？不怪得要反过来骂测试成本高，没有用。一般会出现这种情况，可能是因为是先写完代码再补的测试，或者对代码的接口和抽象不明确所导致。

另外，还有一些测试（比如下文要看到的 saga 官方推荐的测试），它需要测试实现代码的执行次序。这也是一种「关注内部实现」的测试，这就使得除了业务目标外，还有「执行次序」这个因素可能使测试挂掉。这样的测试也是很脆弱的。

表达力极强

表达力极强，讲的是两方面：

• 看到测试时，你就知道它测的业务点是啥

• 测试挂掉时，能清楚地知道业务、期望数据与实际输出的差异

这些表达力体现在许多方面，比如测试描述、数据准备的命名、与测试无关数据的清除、断言工具能提供的比对等。空口无凭，请大家在阅读后面测试落地时时常对照。

快、稳定

不快的单元测试还能叫单元测试吗？一般来讲，一个没有依赖、没有 API 调用的单元测试，都能在毫秒级内完成。那么为了达到快、稳定这个目标，我们需要：

• 隔离尽量多的依赖。依赖少，速度就快，自然也更稳定

• 将依赖、集成等耗时、依赖三方返回的地方放到更高层级的测试中，有策略性地去做

• 测试代码中不要包含逻辑。不然你咋知道是实现挂了还是你的测试挂了呢？

在后面的介绍中，我会将这些原则落实到我们写