为 Playwright API 编写抽象层

Question

我们开始使用 Typescript 中的 Playwright 编写 E2E 测试。到目前为止，我们使用 Selenium，并编写了一个抽象层或一个客户端，它包装了我们的 E2E 测试使用的每个 Selenium 函数。通过 Google 的简单搜索，您可以看到不同的人为 Selenium API 编写的许多不同的客户端。 但是，我没有找到 Playwright 的一个客户端，我想知道我们是否应该实现它？也许是因为 Playwright 已经提供了一个高级 API，旨在易于使用和理解。

我们这样做的主要原因是：

1. u200d提高可靠性和稳定性： 由于 Playwright 包装器可以提供附加功能，因此它们可以帮助提高自动化测试的可靠性。通过更轻松地编写不太可能失败的测试，Playwright 包装器可以帮助确保测试提供“准确且一致的结果”。即：通过使用 Playwright 函数 def fill(text: str)，我们可以在文本字段中输入文本。如果我们为此函数编写一个包装器，默认情况下也会等待直到显示文本，我们将获得更稳定的结果。就此而言，Playwright 提供了异步匹配，它将等待直到满足预期条件。剧作家鼓励这样做，如其

   文档

   中所指定：these matchers allows making the tests non-flaky and resilient
与 Playwright 的 API 解耦：
2. 通过使用 Playwright 的客户端，我们的测试代码与客户端的 API 交互，而不是直接与 Playwright 的 API 交互。如果 Playwright 经历重大更改或引入重大更新，我们只需要更新包装器即可适应这些更改。我们的其余测试代码不受影响，从而减少了维护自动化套件所需的工作量。即：Selenium 在 4.0 版本中的不同功能和组件中引入了许多“重大更改”。幸运的是，由于我们使用的是包装 Selenium API 的客户端，因此测试代码不受影响，我们只需要更新客户端即可。 错误处理和报告：包装器可以实现一致的错误处理策略，并在发生异常时提供有意义的错误消息
3. 因此，我的问题是，您会建议在 Playwright 上写一个抽象层吗
？

我试图在 Google 中找到 Playwright 的抽象层的实现，但没有找到任何东西。

大约一年前，我将大量 e2e 测试从 selenium 迁移到了 playwright。迁移相对轻松，因为我已经在我的 Selenium 测试中使用了抽象层，并且大多数情况下只需要迁移该层本身。根据我的经验，并假设 Playwright 会自行发展，并且将来可能会有其他东西，我强烈建议如果可能的话保留抽象层。我个人使用通用、特定于应用程序和特定于页面的页面对象的层次结构，这些对象被实现为 TypeScript 类，这些类继承自每个对象作为抽象层。我希望这有帮助。

Answer 1