[microsoft/playwright][功能] html-reporter 中的“接受新快照”按钮

2024-07-12 432 views
9

大家好。最近,我们在项目中引入了使用 Playwright 的屏幕截图测试。这些测试效果很好 - 每次发布时它们都会发现 UI 错误。我们开始增加它们的数量,但很快就遇到了问题。

我们的工作流程如下:我们在 Playwright 配置中创建了一个单独的项目 - 纯粹的 UI 测试,与功能测试分开运行。运行后 - 我们在标准 Playwright html-reporter 中查看结果。总的来说,它非常方便。它突出显示了差异,您可以同时查看原始屏幕截图和新屏幕截图 - 一切都很酷。

但相对常见的情况是,测试失败是出于正当理由。不是因为某些错误,而只是因为某些 UI 被更改,可以说,这是预期的失败。但在查看失败的测试时,重要的是不要错过那些真正因错误而失败的测试。

问题是,现在,在运行测试之后,需要更新 20 个“有效”失败的测试并接受新的原始测试,但对于 5 个测试,这是没有必要的,因为它们由于错误而失败,没有工具可以这样做。您必须使用 再次运行测试--update-snapshots,在这种情况下不会生成差异。然后,您需要坐在 IDE 中观察并检查哪些图片可以提交,哪些不需要。此外,稳定性并不总是 100%,有时会有不稳定性测试,也需要查看它们,以免它们被意外提交,等等。简而言之,处理这个问题的开销很大。

为每个失败的测试单独设置“接受新的”按钮 - 将完全解决这个问题。因此,我真的想要一个像“接受新的黄金快照”这样的按钮,这样对于每个失败的测试,都可以接受一个新的屏幕截图作为新的原始截图,之后,它会在磁盘上的屏幕截图目录中被替换,它会出现在 git 的 diff 中,你只需要提交它。

此外,最好按下此按钮将测试变为“绿色”,也就是说,它将使测试从失败变为通过。

我不知道有多少人使用 Playwright 进行截图测试,但我认为每个使用的人都有同样的问题。Playwright 基本上提供了截图测试所需的一切,唯一缺少的是一种方便的截图管理方式。

回答

1

嘿。我目前正在实现此功能。计划今天发送 PR。但我不是剧作家团队的成员,所以我必须获得批准并与他们讨论细节。

9

好的,接受截图按钮本身大部分已经准备好了:

然而,我在实施上述测试状态更新时遇到了一些问题,需要更多时间来解决问题。

1

您在这里使用什么来运行测试?是调试器吗?我们不会在启用跟踪的情况下运行测试,因为这会大大减慢测试速度。

4

这是 Playwright UI 模式:https://playwright.dev/docs/test-ui-mode 通常用于在本地开发期间运行和调试测试。您不必在 CI 中使用跟踪即可使用它。

我正在开发的功能与静态 HTML 报告或您在 CI 运行中可能生成的其他报告无关。我专门将这些按钮添加到 UI 模式中。

2

我们不使用 UI 模式,这对我们来说不是很方便,正如我在功能标题中提到的,我们希望在 html-reporter 中专门使用它。

4

我们不使用 UI 模式,这对我们来说不是很方便,正如我在功能标题中提到的,我们希望在 html-reporter 中专门使用它。

啊,好吧,那有点误会了。我正在专门为 UI 模式开发此功能。

至于 HTML 报告,到目前为止,实现起来实际上相当困难(如果不对剧作家架构进行重大改变,甚至根本不可能):

  • 为了更新截图,我们需要访问 FS,但目前,HTML 报告是一个独立的文件夹,其中的文件可以作为网页提供,没有服务器对应部分
  • HTML 报告旨在与项目分离。例如,它可以上传到 S3 或其他地方,然后接受其中的屏幕截图就没有意义了

是什么阻碍了你使用 UI 模式?也许我们可以朝这个方向思考并解决 UI 模式问题,对我来说这听起来更现实

7

我们不使用 UI 模式,因为在常规无头模式下测试运行速度明显更快,而且通常我看不到此模式的任何附加价值,但也许我没有充分使用它来看到它的好处。常规--debug通常足以用于调试目的...

8

我认为我和其他 Playwright 用户无法使用 UI 模式的原因如下:

  • 首先,使用命令行“npx playwright test --headless”,UI 模式的运行速度比正常模式慢。
  • 其次,UI 模式不会自动生成 HTML 报告。这使得结果本身毫无价值。
  • 第三,html 报告足以让您了解正在发生的事情(它提供跟踪、屏幕截图、视频……),如果您是实施测试用例的人,那么您只需不到 30 秒就能知道错误是什么。而且自动化调试比应用程序本身容易得多。那么 UI 模式是干什么的呢?
  • 第四,普通模式生成的“实际”图像可能与 UI 模式生成的“实际”图像不同。因此,如果我们想接受普通模式的图像,我们有什么选择?除此之外,在 UI 模式下运行将覆盖普通模式已经生成的实际图像。所以我们必须在 UI 模式下第二次运行它才能批准图像?(这是毫无意义的)=> 我认为您创建“批准”按钮的想法很好,但必要性和实施性相当微不足道。只是我的意见。
2

@shadowusr 我很欣赏你所做的工作,这真的很有用。

我想说@nikolay-yavorovskiy 的观点很正确,我也认为在 HTML 报告中拥有这种功能会很棒。

我想到的解决办法是,报告的 HTML 可以支持生成补丁文件或脚本。这样报告页面上的一小段 JS 脚本就可以生成开发人员可以在本地应用的补丁。

实现此目的的一种方法是创建一个包含所有二进制图像数据的真正的 git 补丁文件。我认为这在纯 JS 中很难。

另一种方法是创建一个小型 bash 脚本,该脚本可以从当前查看报告的来源获取图像。这对我们很重要,因为我们希望我们的 CI 系统托管报告文件。我们的梦想是能够更新预期图像,而无需在开发人员机器上本地生成屏幕截图。此处提出的补丁脚本可以由开发人员运行,它会从 CI 系统托管的 playwright html 报告中将新的预期图像提取到正确的文件夹中。然后开发人员可以提交新图像。

我一直在考虑在 Tampermonkey 脚本中生成该补丁代码,但如果在官方 html 报告器中看到此功能就太好了。

6

@GotBinGo 需要说明的是,我暂时停止了此功能的开发,因为剧作家团队还没有准备好合作完成如此大规模的贡献,而且对此功能有不同的看法。我认为最好是等他们实现它,或者等有人与维护人员讨论完所有细节后再尝试贡献

3

@aslushnikov,嘿!这个问题已经搁置了一段时间了,所以我想知道目前的状态如何,什么时候可以实现这个功能?

没有任何压力,只是想知道我们是否可以指望在不久的将来发布。如果我能做些什么(以某种方式提供帮助或贡献代码)来加快速度,请告诉我。

7

嘿@shadowusr,暂定于 1.39!

4

@aslushnikov 我们非常期待这个功能。它对于视觉测试来说绝对必不可少。

5

@aslushnikov 嗨,安德烈。我看到 1.39 标签已被删除,所以我们近期不应该期待这个功能??