真的假的？我们如何通过从Cypress迁移到Playwright，将测试时间缩短70%

以下为作者观点：

"从Cypress测试中移除 .only"--这条提交信息听起来熟悉吗？如果你使用 Cypress进行过端到端测试，你就会明白我在说什么。

在这之前，我们（团队）使用 Cypress 构建了一个包含 200 多个测试用例的庞大套件。虽然 Cypress 是一款强大的端到端测试工具，但我们对 Playwright 还是很感兴趣。Playwright 是微软开发的一个快速发展的开源框架。改进的速度、统一的语法和跨浏览器支持的承诺引起了我们的兴趣，于是我们决定试一试。

在本文中，我们将分享从 Cypress 迁移到 Playwright 的原因和过程、Playwright 的主要优势以及我们在迁移过程中遇到的困难。

如果你们正在考虑进行同样的迁移，这篇文章可能会给到一些参考。

我们为何迁移

我们在一个较小的 React 应用程序中试用了 Playwright。包括学习 Playwright API 所花费的时间，两天后，我们就完全迁移了测试套件。这个过程中，我们亲身体验到了Playwright的主要优势。

• 速度

Playwright 的速度明显快于 Cypress。在本地开发机器上，Playwright 测试套件的运行速度是 Cypress 测试套件的3倍。在 GitHub CI 中，Playwright 比 Cypress 快2倍。

并行性和分片

速度的提升已经让我们相当左对齐兴奋了。怎么会快这么多呢？

原因之一是 Playwright 支持开箱即用的并行测试。理论上，Cypress 允许你执行并行测试。不过，免费版的使用相当不便。

Playwright 能够让你控制同时运行的工作进程数量，并限制测试失败的总次数。默认情况下，Playwright 会按顺序运行单个文件中的所有测试，但你也可以选择并行运行。

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  fullyParallel: true,
  retries: process.env.CI ? 3 : 0,
  workers: process.env.CI ? 1 : undefined,
});

Playwright 还支持开箱即用的分片。在 Cypress，我们不得不编写一个非常麻烦的脚本，将我们的测试套件划分为不同的分片，因为分片只在他们的付费计划中提供。Playwright 让分片变得简单。它允许分割测试并同时在不同的机器上运行，从而节省了大量的CI分钟时间。

npx playwright test --shard=1/3
npx playwright test --shard=2/3
npx playwright test --shard=3/3

统一语法

Playwright 使单元测试和端到端测试之间的切换更加顺畅。

我们在使用 Cypress 时面临的另一个问题是需要不断地在 Cypress 语法和 Jest 语法之间进行上下文切换。有了 Playwright，我们现在可以在单元测试和 E2E 测试之间使用相同的语法。Cypress 看起来不太像 JavaScript，而更像是专门为其自己的领域设计的独特框架。

因此，编写 Cypress 测试总是需要使用不同的思维模型。在编写测试时，我们经常发现自己混淆了诸如.toBeVisible和.should(‘be.visible’) 之类的断言。

任何 JavaScript 开发人员都会发现 Playwright 测试非常容易掌握。它涉及使用async函数、等待 Promise 以及将函数return值分配给变量。

test('Lingvano logo is visible', async ({page}) => {
    await page.goto('/home');

    const logo = page.getByTestId('lingvano-logo');
    await expect(logo).toBeVisible();

    await logo.click();

    await expect(logo).not.toBeVisible();
  });

开发者经验

使用Cypress，通常的测试工作流程是：通过终端打开 Cypress 窗口，搜索规范，然后运行相应的测试。哦，实际上只是想运行一项特定测试？然后你将返回代码编辑器，将测试标记为.only，然后返回 Cypress 窗口。这可能会变得很烦人。

在开发人员体验方面，Playwright 改变了游戏规则。

首先，Playwright VSCode 扩展能与代码编辑器顺利集成。只需单击一下，就可以运行整个流程或单个测试用例，而无需离开编辑器。现在，Intellij IDE 的 EAP 版本原生支持 Playwright。

你知道当测试失败但又不知道是哪一行失败时的沮丧感觉吗？Playwright 通过高亮显示测试失败的确切代码行，让调试变得更容易。心里感叹，再也不用无休止地滚动日志来查找错误信息了。

Playwright VSCode 扩展

如果你喜欢在单独的窗口中查看测试，Playwright 也提供了直观的UI 模式。这方面它与 Cypress 窗口类似，但提供了更多的功能。

通过它，你可以查看跟踪记录、穿越测试运行时间，并在观察模式下运行测试。如果你像我们一样以测试为导向，你会发现观察模式在开发过程中非常有用。

此外，用户界面模式还可以直接从 DOM 快照中选取定位器，并检查每个操作的网络日志。

Playwright用户界面模式

• 跨浏览器支持

让我们着迷的另一个原因是 Playwright 的跨浏览器支持。虽然Cypress 目前支持 Firefox 和 Chrome 系列浏览器（包括 Edge 和 Electron），但它仅对Safari 浏览器引擎 WebKit提供实验性支持。

Playwright 支持 Chromium、Firefox 和基于 WebKit 的浏览器（例如 Safari）以及 Edge。与 Cypress 一样，它也可以在headed模式和headless模式下运行测试。

于是我们从Cypress开始迁移200多个测试

我们被 Playwright 说服了，并准备迁移 React Native 应用程序的测试套件。但您可能会问，迁移 200 多个测试的最有效方法是什么？

最初，我们依靠 GPT4 将测试从 Cypress 重写到 Playwright。我们向 GPT4 提供了一些示例，让它根据这些示例重写测试用例。结果发现，GPT4 并不掌握 Playwright 的最新语法，而且经常提出不存在的断言。

然后我们切换到 GitHub Copilot，步骤如下：

1.复制 Cypress 测试用例

2.开始输入 Playwright 测试用例

3.让 Copilot 完成测试用例

还别说，这个还非常有效和可靠。最终，我们用了两周左右的时间完成了迁移。

可能遇到的挑战

在大多数情况下，迁移进行得很顺利。然而，和对新框架的任何更改一样，我们在此过程中确实遇到了一些障碍。

• WebKit 的不稳定性

虽然在 Mac 本地运行 WebKit 测试非常顺利，但在我们的 GitHub CI 管道中却相当缓慢和不稳定。

• 集成 MSW 和 Playwright

我们使用 MSW 模拟 API 请求，用于开发和自动化测试。

到目前为止，Playwright 还没有与 MSW 完全集成。Playwright 的窗口上下文不支持 MSW，这使得覆盖 MSW 处理程序变得困难。Playwright 建议使用其内置的网络模拟，而不是依赖第三方库。
 

总结

虽然Cypress 无疑也是一款出色的工具，但迁移到 Playwright 后，我们的开发人员体验得到了改善，端到端测试执行速度也加快了。我们发现 Playwright 是一款功能强大的工具，它支持并行性和分片、统一语法和跨浏览器支持。

然而，与任何过渡一样，迁移过程也并非没有挑战。就我们而言，我们遇到了 WebKit 脆弱性和 MSW 集成的问题。尽管存在这些障碍，但我们还是利大于弊，我们对 Playwright 的发展前景充满信心。

你们是否有过类似的转变？

最后：下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。