Slack 如何使用 AI 驱动的混合方法将 Enzyme 迁移到 React 测试库

Sergii Gorbachov 在 旧金山 QCon 表示，Enzyme 缺乏对 React 18 的支持，导致其现有的单元测试无法使用，并危及了他们提供的基本信心。他展示了 Slack 如何将所有的 Enzyme 测试迁移到 React 测试库（React Testing Library，RTL），以确保其测试覆盖率的持续性。

React 测试库是业界公认的选择，React 18 并没有其他官方支持的替代品。Gorbachov 说道，这使得这个决策变得简单明了，并且符合最佳实践。

Enzyme 的方法强调了测试内部组件的细节，比如状态、属性和实现细节。Gorbachov 说，切换到 React 测试库引入了一种不同的方法，侧重于模拟用户在真实环境中如何与组件及其行为进行交互。

他们首先使用大语言模型（LLM）作为一个独立的工具，依靠它来生成完全转换和功能测试。Gorbachov 提到，虽然这种方法取得了部分成功，但其有效性因测试的复杂性而异。

接下来，他们将 LLM 集成到一个更大的管道中，将其与抽象语法树（AST）转换相结合，并结合验证、linting 和迭代反馈的步骤来修复第一次的尝试，正如 Gorbachov 所解释的那样：

这种混合方法兼具两种方法的优点，帮助我们实现了 80% 的转换成功率，在保持测试质量的同时显著提高了效率。

为了评估所生成代码的质量，他们创建了一个详细的质量标准，评估了 codemod 功能（可靠性和错误处理）、导入转换（用 RTL 等效替换 Enzyme 导入）、渲染（将 Enzyme 渲染转换为 RTL）、Enzyme 方法（替换 Enzym 方法或添加注释）、断言（更新为与 RTL 兼容的断言）以及 JS/TS 逻辑（保留测试功能）：

我们从每个难度级别（简单、中等和复杂）中选择了三个 Enzyme 测试文件，并手动评估了它们以衡量我们的进度。难度是根据测试用例、导入、Enzyme 方法和断言的数量等特征确定的，测试用例的权重更大，平均复杂度评级以将文件置于其中一个难度级别为标准。

他们自动转换文件，并使用质量标准评估结果，以人工转换的文件为基准。Gorbachov 表示，他们的工具平均准确率为 80%，但在更复杂的情况需要手动调整。

Gorbachov 表示，将确定性方法与人工智能相结合有助于克服其局限性，例如缺乏实时反馈以及对预处理和后置处理的依赖。他补充道，通过集成基于 AST 的转换、注释和精心制作的提示，他们将转换成功率提高了 20-30%，超过了 LLM 的开箱即用功能，即在人工工作流程之后对上下文进行建模。

虽然 LLM 在处理高复杂性、非结构化任务方面表现出色，但对于确定性的任务，最好避免使用 LLM，但正如 Gorbachov 所解释的那样：

我们的方法包括生成代码的执行和验证，可以转移到像单元测试生成、代码现代化和可读性改进这样的项目中，从而实现完整的端到端流程。

为了重用这种方法并为其他类型的项目构建类似的管道，Gorbachov 引用了 Enzyme 到 RTL codemod、用于完整实现的 convert-test-files 工作流程，并在 Slack 上发表关于 AI 驱动的从 Enzyme 到 React 测试库转换的博客文章。

InfoQ 就他们迁移到 React 测试库的问题采访了 Sergii Gorbachov__。

InfoQ：你们是如何调整自动化测试的？

Sergii Gorbachov：例如，考虑以下代码：

<div><button onClick={toggle}>Toggle</button>    <p>{isOn ? "Switch is ON" : "Switch is OFF"}</p ></div>

使用 Enzyme，我们可以这样测试这种行为：

wrapper.setState({ isOn: false });expect(wrapper.find('p').text()).toBe('Switch is ON');

这直接操纵组件的内部状态来断言结果。在 RTL 中，我们模拟用户交互：

userEvent.click(screen.getByText('Toggle'));expect(screen.getByText("Switch is ON")).toBeInTheDocument();

这种方法侧重于验证用户操作的结果，并确保组件的行为符合用户的预期，而不是侧重组件的内部工作原理。

InfoQ：使用抽象语法树 codemod 和大语言模型有什么好处？

Gorbachov：使用抽象语法树（AST）codemod 和大语言模型（LLM）显著增强了测试转换过程。我们团队创建的 AST codemod 处理了简单的代码转换，并为规则过于模糊而无法通过编程定义的复杂场景添加了注释。

例如：

expect(component.find('div')).toHaveLength(2);

将转换为：

// 转换建议：.find（'div'）-->使用组件渲染的 DOM 获取适当的选择器和方法：screen.getByRole（'selector'）或 screen.getByTestId（'<dataid=......>'）expect(component.find('div')).toHaveLength(2)

该注释是专门为 LLM 创建的，并提供了详细且相关的指导，以帮助模型针对该特定的实例生成准确的转换。大多数此类实例都在原始文件中进行了注释，这些文件被用作转换的源代码。通过在 LLM 提示中包含部分转换的伪代码和注释以及定制的指令，我们减少了歧义，并最大限度地减少了仅依赖提示的 AI 方法中常见的幻觉。

作者介绍

Ben Linders 是一位来自荷兰的敏捷、精益、质量和持续改进方面的独立顾问。他著有《从敏捷回顾中获得价值（Getting Value out of Agile Retrospectives）》、《Waardevolle 敏捷回顾（Waardevolle Agile Retrospectives）》、《是什么推动了质量（What Drives Quality）》、《敏捷自我评估游戏（The Agile Self-assessment Game）》、《问题？什么问题？（Problem? What Problem?）》以及《持续改进（Continuous Improvement）》。并且是许多 敏捷辅导工具 的创建者，例如敏捷自我评估游戏。作为一名顾问、教练和培训师，他通过部署有效的软件开发和管理实践来帮助组织。他专注于持续改进、协作和沟通以及专业发展，为客户提供商业价值。Ben 是敏捷、精益和质量网络的活跃成员，也是一位经常演讲和写作的人。他在一个双语博客（荷兰语和英语） 中分享自己的经验，并在 InfoQ 担任敏捷方面的编辑。可以通过 @BenLinders 在推特上关注他。

原文链接：

https://www.infoq.com/news/2024/12/ai-enzyme-react-test-library/