使用 React 测试库进行无障碍优先集成测试

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

通常，我们在讨论无障碍测试时，会重点关注以下两方面：

• 浏览器扩展程序代码检查工具（例如Axe和Wave）
• 手动测试，例如使用屏幕阅读器

不过，在集成测试中也可以采用以可访问性为中心的方法，对于 React 开发人员来说，React Testing Library是完成这项工作的完美工具。

“嘿，我用的是酶，有什么问题吗？”

问得好。Enzyme是一个非常流行的 React 集成测试库。但是， Enzyme中的测试模拟的是开发者的视角，而不是最终用户的视角。

一般来说，Enypherd 测试的工作原理是测试组件的实现，而不是用户体验。我们会断言预期的元素是否由其父组件渲染，以及 props 是否存在且正确。我们会直接调用回调函数，并验证状态等的预期更新。

像这样测试实现方式存在一些主要缺点：

1. 开发人员的疏忽更难被发现——当我们测试自己实现的组件时，我们很可能重蹈覆辙，再次犯下之前在实现过程中做出的任何假设或错误。

2. 我们未能全面测试用户交互路径。我们可能已经检查了屏幕上渲染了多少个项目，但我们并没有真正检查这些项目是否可感知和可操作。可感知和可操作是无障碍应用程序的两项核心要求（更多关于 POUR 的信息，请参阅 WebAim 的这篇文章：构建 POUR 网站）。

React 测试库：无障碍优先

React Testing Library 的理念与 Enzyme 不同，初次使用时可能需要一些时间来适应。其方法可以概括为：

• 测试真实交互
• 验证可感知结果

在组件树的较高层进行测试

为了真正关注真实的用户交互，我们应该减少对单个底层组件的孤立测试。相反，我们应该问自己：

为了测试一组真实的用户交互，我需要渲染页面的多少内容？

对于某些应用来说，答案可能是整个页面。而对于另一些应用来说，可能只是某个子部分。用视觉化的方式思考会有所帮助：如果你要将应用交给同事手动测试一组特定的功能，你会希望他们查看页面的哪些部分？

测试项目是否可感知的查询

React Testing Library 提供了几个查询语句，我们可以用它们来定位和验证渲染后的项目，包括：getByLabelText`get_return_items( getByAltText)`、`get_return_items()` 等等。他们有一个很棒的常见问题解答，讲解了应该使用哪个查询语句，并按优先级进行了排名：我应该使用哪个查询语句？

这正是无障碍优先方法真正发挥作用的地方。

与其通过用户无法感知的某些属性（例如类名）查询 DOM，不如使用能够突出显示辅助功能缺陷的查询。

例如，getByLabelText这是检查输入字段的首选查询。如果您无法通过这种方式获取输入字段的句柄，则测试过程会提示您存在一个非常重要的可访问性问题。

测试项目是否可操作的操作

一旦获取到元素的句柄，就可以使用fireEventAPI 执行点击和其他用户交互。虽然fireEventAPI 并不能完全复制用户交互（文档中有对此的详细解释：交互与事件），但它确实允许我们验证元素是否存在、是否响应点击事件，以及是否可操作。

我们无需像使用 Enzyme 那样通过监控内部状态或属性变化来验证点击事件，而是可以验证用户是否收到了相应的反馈。例如，如果点击了“添加到购物车”按钮，我们可以验证购物车计数图标最终是否从“0”变为“1”，或者是否出现了“继续结账”的确认信息。我们通过可感知的结果来衡量操作的成功与否。

结论

总而言之，React Testing Library 的设计理念是为我们的测试赋予以用户为中心的视角。更重要的是，它的查询语句设计将可访问性置于这一视角的核心位置。

你已经从 Enzyme 切换到 React Testing Library 了吗？请告诉我你的使用体验，或者你觉得两者之间有哪些取舍。就我而言，目前为止，切换非常成功🙌

你觉得这篇文章有用吗？如果可以的话，请我喝杯咖啡，这样我才能继续创作内容哦🙂