1、初识快照回归测试：什么是快照测试、为什么需要离线优先、适用于哪些场景
什么是快照测试？说白了就是给UI拍个“身份证照”
我记得刚做Compose那会儿，经常遇到这种情况：改了一行padding，结果整个页面的布局全歪了。而且更气人的是，这种问题往往不是编译报错能发现的——你只能靠肉眼一点点去对比。
快照测试（Snapshot Testing）就是干这个的。它的原理很简单：
- 第一次运行测试时，把你的UI组件渲染成一张图片（或者一串文本描述），保存下来作为“基准快照”
- 后续每次改动代码后重新运行，再生成一张新快照
- 把新旧两张快照做像素级对比，差异超过阈值就告警
你可以理解成每次提交代码时，系统自动帮你截一张UI的“身份证照”，然后跟你上一次的“证件照”叠在一起做差分。只要有一丁点儿变化，它都能找出来。
为什么需要离线优先？
你这个项目跑在CI上，每次commit都触发几十个快照对比。假设CI环境没有网络，或者镜像拉不下来、云端服务挂了——整条流水线就得卡死。
我最初在团队里推快照测试时，就踩过一个坑：我们依赖一个第三方的云对比服务，结果有一次那个服务维护了6小时，所有PR的UI检查全部黄灯。后来我改成了本地离线对比方案，再也不怕网络波动了。
离线优先（Offline First）的核心原则：
- 所有基准快照都存储在本地仓库（Git LFS或普通文件目录）
- 对比逻辑完全本地执行，不依赖任何外部API
- 报告生成也是纯离线，HTML、JSON文件直接输出在构建产物里
说白了，你的测试环境就是一台没有网也能跑的“单机版”UI检测机。
适用于哪些场景？
不是所有UI变动都需要快照测试。它最适合以下三种场景：
| 场景 | 典型例子 | 为什么快照适合 |
|---|---|---|
| 高频迭代的视觉组件 | 按钮、卡片、弹窗、列表项 | 每次改样式后自动验证，防止“改了A、炸了B” |
| 跨平台UI一致性 | 同一Compose代码跑在Android、Desktop、Web | 快照可以对比不同平台的渲染结果是否一致 |
| CI回归流水线 | 每个PR都要过UI检查 | 离线快速执行，不排队，不依赖外部资源 |
我个人习惯，会把快照测试放在单元测试之后、集成测试之前。因为它跑得很快（毫秒级），可以尽早阻断明显出错的UI。
你想想看，如果有这样一个场景：你的某个Compose组件在夜间被其他人改过背景色，但没人注意到。第二天发布的线上版本就变成了“五彩斑斓的黑”——是不是很恐怖？快照测试提前一天就能把这个变化揪出来。
快照回归测试的典型流程
下面这张图可以一目了然地看清整个工作流：
避坑指南：我曾经踩过的那些坑
快照测试虽然好用，但也不是无脑接入就能爽。我梳理了几个常见问题：
- 基准快照膨胀问题：每次迭代都生成新快照，仓库体积会飞速增长。我建议用Git LFS管理，或者只保留最后一次通过的基线版本，必要时手动清理。
- 像素差异的“假阳性”：不同操作系统的抗锯齿策略不同，同样的Compose代码在macOS和Linux上字体渲染可能差几个像素。解决办法：设置一个合理的容差值（比如0.1%），或者在CI环境统一使用容器内的无头渲染。
- 团队协作冲突：两个人同时改同一个组件，各自更新了快照——合并时就会冲突。我的经验是：快照文件作为测试产物不要手动修改，冲突时直接删掉重新跑一次测试就好。
什么时候不该用快照测试？
嗯，这里也要提醒你：快照测试不是万能的。以下场景我通常会避开：
- 动态内容过多的页面（比如带实时刷新的Feed列表）——快照每次都不一样，告警毫无意义
- 动画或转场过渡——快照只取一帧，无法覆盖时间维度的变化
- 极端低频的UI组件（比如一年改一次的免责声明页）——维护快照的开销超过了收益
核心观点：快照回归测试的价值不在于“发现所有Bug”，而在于“用最小成本感知到UI的意外变化”。离线优先则是保证这个感知过程在任何环境下都能稳定执行。
我个人最喜欢快照测试的一点：它的反馈极度直观。即使是刚入职的新人，看到两张图叠在一起、差异部分标红，也能立刻知道“噢我的改动影响了那个间距”。这种直观性，比你写一百行断言代码都管用。