安卓截图测试#

#为什么我们要进行截图测试？

屏幕截图测试用于验证当前 UI 是否与存储库中存储的参考 UI 匹配。通过这样做，我们可以确保影响 UI 的任何更改都是有意为之且经过验证的。这些测试的范围仅限于 UI。

我们应该在各种设备形状和尺寸上进行测试，从小屏幕（例如，Wear OS 设备）到大屏幕（例如，55 英寸电视）。

#屏幕截图测试的好处

• 用户界面一致性：确保 UI 在更新中保持一致。
• 图书馆更新：验证 UI 库的更新不会引入意外的更改。
• 广泛的设备覆盖范围：跨多种屏幕尺寸和形状进行测试以确保兼容性。

#现实世界的例子

事实证明，在使用测试版库（例如 Wear Compose 库）时，屏幕截图测试非常有用，库中的更改可能会影响 UI。

#编写截图测试

我们使用 Compose Preview Screenshot Testing 框架来断言 UI 不会意外更改。

#撰写截图测试的优点

• 无需模拟器：这些测试不需要模拟器，因此比integration tests 占用的资源更少，并且速度明显更快。
• 快速反馈：开发人员可以快速验证 UI 更改，而无需等待模拟器启动时间。

#参考截图

参考屏幕截图存储在每个 Gradle 模块中的 src/debug/screenshotTest/reference 下。要更新参考屏幕截图，请运行以下命令：

./gradlew updateDebugScreenshotTest updateFullDebugScreenshotTest

#CI集成

我们的CI pipeline 验证测试报告是否有任何错误。如果发现差异，CI 会阻止拉取请求，直到问题得到解决。

#避免 Compose 预览中的重复

为了避免在测试中重复 Compose 预览，请确保尽可能重用现有的可组合项并预览注释。这减少了冗余并确保预览和测试之间的一致性。

#为测试配置注释

编写屏幕截图测试时，使用适当的配置注释来定义设备大小、主题和其他参数。这可确保测试准确反映预期的 UI。

#处理阈值更新

在不同操作系统上运行时，由于渲染方面的细微差异（例如抗锯齿），屏幕截图测试可能会失败。这个问题在Google issue tracker中有详细讨论。

#目前的方法

我们将门槛保持尽可能低，以避免掩盖真正的问题。

GitHub Action 工作流程 update_screenshots.yml 可用，并且可由存储库维护人员手动触发以更新屏幕截图，使其与验证主机配置匹配。如果您的屏幕截图测试由于阈值差异而失败，维护人员将在审核过程中解决此问题。

#屏幕截图测试的最佳实践

• 跨设备测试：确保您的测试涵盖一系列屏幕尺寸和形状。
• 保持参考屏幕截图更新：定期更新参考屏幕截图以反映有意的 UI 更改，并在 PR 中解释这些更改。
• 最小化阈值：使用尽可能小的阈值以避免隐藏真正的问题。
• 重复使用预览：通过重用现有的可组合项和注释来避免重复 Compose 预览。

通过遵循这些做法，您可以确保您的 UI 在更新和设备配置中保持一致和可靠。