截图测试是验证应用 UI 的一种非常有效的方法。截图测试可以存在于组件、功能和应用程序测试中。
您可以使用第三方工具创建工具测试和本地截图测试。如果您使用 Compose，可以使用官方的 Compose 预览截图测试工具。
定义
截图测试会截取 UI 的屏幕截图，并将其与先前批准的图像（称为“参考”或“黄金”图像）进行比较。
如果图像相同，则测试通过。如果它们之间存在差异，则工具会创建报告。
通过报告，您可以有两种可能的回应：
- 意识到新代码中存在错误并进行修复。
- 批准新截图并将参考图像替换为新图像。
截图测试与常规测试的工作流程不同，因为失败的测试并不总是意味着存在错误。
优点
截图测试的优点是：
- 一次截图测试可以进行多个断言。例如，单个测试可以检查颜色、边距、大小和字体。
- 与等效的行为测试相比，截图测试更容易编写、理解和维护。
- 它们在验证和捕获不同屏幕尺寸上的回归方面特别有用。
缺点
但是，截图测试也可能存在缺点：
- 处理参考图像可能很麻烦，因为大型项目最终可能包含数千个 PNG 文件。
- 不同的平台（Linux、Max 和 Windows）会生成略微不同的截图。
- 它们比等效的行为测试慢。
- 拥有大量截图测试可能会导致问题，例如当单个更改影响数千张截图时。
以下部分提供解决这些问题的建议。
将截图测试保持在最低限度
您应该尽量减少截图测试的数量，同时最大限度地提高回归反馈和覆盖率。
不同 UI 状态的组合会使测试数量迅速增加。以下是您可以验证应用 UI 部分的一些方法：
- 在不同的主题上
- 使用不同的字体大小
- 在不同的屏幕尺寸或边界内
如果您对应用的每个组件、布局和屏幕都这样做，最终会得到数千个截图文件，其中大部分不会为您提供任何额外的反馈。
例如，如果您想测试具有浅色和深色主题以及 3 种字体大小的自定义按钮，则无需创建所有这些组合。相反，您可以只选择一个主题。这是因为按钮对长单词的反应方式对主题没有影响。
存储参考图像
参考（或黄金）图像通常是 PNG 文件，可以检入您的源代码管理。但是，Git 和大多数源代码管理工具都针对文本文件进行了优化，而不是大型二进制文件。
您可以使用 3 种方法来管理这些文件：
- 继续使用 git，但尝试最小化存储使用。
- 使用 Git LFS。
- 使用云服务来管理截图。
平台差异
截图测试依赖于底层的平台API来绘制特定的特性，例如文本或阴影，而不同平台的实现方式可能有所不同。如果您在Mac上开发并保存本地拍摄的新截图，则可能会在Linux CI机器上看到测试失败。
有两种方法可以解决这个问题
- 容忍细微的差异
- 在服务器上拍摄截图
容忍细微的差异
您可以配置大多数截图测试库，以便在比较两张截图时允许存在细微的差异。
这有两种方法：
- 基于修改像素的百分比或像素值总差异的百分比配置容差。
- 使用智能差异算法——比较截图的算法——来验证结构和语义相似性，而不是像素。
这种方法的缺点是可能会产生误报，并且无法捕获低于阈值或错误地认为足够相似的错误。
在服务器上拍摄截图
要使用像素级精确的截图比较器，您必须确保您的测试在相同的条件下拍摄截图。为此，您可以使用持续集成 (CI) 系统或使用云服务。
例如，您可以在CI工作流程中创建一个步骤，执行以下操作：
- 运行截图测试（仅在不使用像素级精确匹配时才需要）。
- 如果上一步失败，则记录新的截图。
- 将新文件提交到分支。
使用这种方法，截图测试在CI上永远不会失败，但是它会为您修改更改。这样，您和更改评审者可以通过合并更改来接受新的截图。
截图测试工具
考虑以下可用的截图测试工具和库之间的关键区别：
- 环境：在主机上运行的本地测试，或在模拟器或设备上运行的检测测试。
- 渲染引擎：主机端的截图解决方案可以使用Layoutlib（Android Studio用于预览的渲染引擎）或Robolectric Native Graphics (RNG)。
- 基于Layoutlib的框架专注于渲染静态组件，使用不同的状态来显示不同的行为。它们通常更容易使用。
- 与RNG集成的框架可以使用Robolectric的所有功能，从而允许进行更大范围的测试。