验证UI
构建界面只是第一步。UI变更只有经过真实浏览器驱动并将截图放入PR后才算完成。类型检查、代码规范检查和单元测试仅确保代码编译和逻辑正确，但无法验证面板是否渲染、页脚是否按设计定位。不运行分支的评审人员只能通过截图来判断工作——或者完全无法判断。
1. 在真实浏览器中使用真实数据驱动变更
使用运行中的应用程序搭配真实（种子）数据库，而非模拟数据，并且不要只截图正常路径。遍历设计文档中命名的每个状态，以及那些未明确提及的状态：
- 两种主题。 手写颜色是暗色模式变体容易被遗忘的地方。
- 移动端和桌面端。 布局会在断点处重新排列，页脚和工具栏可能托管其一半内容。
- 空状态、加载状态、极限状态和失败状态， 不仅仅是填充状态。
- 每次切换，其中一个对话框或视图关闭而另一个打开。
- 打开你添加的每个菜单、弹出框和下拉菜单。 从未打开的菜单看起来与打开时导致页面崩溃的菜单一模一样。
- 在此过程中检查浏览器控制台和网络面板是否有错误。
2. 运行审查扫描
对照仓库使用的设计和框架指南（设计系统、无障碍性、框架最佳实践）审查变更。如果你的代理可以生成子代理，则在较便宜模型上并行运行每个指南的审查员。这是模式匹配工作，而非判断。
- 向审查员提供仓库自身的规则。 未阅读规则的审查员会将已记录的决定报告为违规。
- 要求审查员仅报告发现。 然后根据实际概率自行判断每个发现。拒绝那些对于不同产品也成立的结果，例如针对上限为十几行的列表的虚拟化建议。
3. 为PR捕获截图
不是界面的描述：而是界面本身。捕获截图也是捕捉你实际未查看的状态的最廉价方式。
- 驱动真实应用程序。 一个一次性浏览器脚本能够到达每个状态即可。使用E2E测试工具的种子助手到达UI流程无法产生的状态，然后截图存在后删除该脚本。它不进行断言，也不属于测试覆盖率。
- 在捕获前重新构建。 否则你可能截取刚刚修复的bug的截图。
- 等待动画完成后才按下快门。 “可见”在元素布局完成时解析，而非其进入过渡结束时，因此简单的捕获会显示半透明对话框且无背景。等待有限动画（排除无限动画，如骨架屏脉冲）完成，并设置超时。
- 尽可能以用户的方式到达每个状态。 强制设置标志会跳过可能暴露出bug的竞争条件。
- 将截图提交到
docs/screenshots/<topic>/目录， 如果存在对应的设计文档，则将其置于该设计旁。 - 使用提交SHA而非分支引用， 例如
https://github.com/<org>/<repo>/blob/<sha>/<path>?raw=true。分支URL在合并时删除分支后失效，导致PR中出现大量损坏的图片。
无可用浏览器
如果环境确实无法运行UI（无浏览器工具、缺少凭据、无法控制的基础设施），请在PR的“测试”部分说明。说明被什么阻碍以及你验证了什么。沉默会被理解为“已验证”。
将审查修复作为独立阶段提交
此过程中发现的修复应作为后续的堆叠PR堆放在功能之上，以便构建和审查通过保持独立可审查性（参见 stacked-prs）。
此过程能捕获的问题
以下所有问题均未从类型检查器、代码规范检查器或单元测试中发现：
- 与页面不匹配的加载骨架屏。 骨架屏显示了页面没有的工具栏，导致每次导航在两个布局之间跳转。逐行镜像真实布局，否则不要发布骨架屏。
- 切换时同时显示两个对话框， 因为每个对话框都已挂载，仅切换其
open标志。隐藏不等于卸载。 - 错误身份闪现： 用户自己的行在一次渲染中提供删除自身选项，因为客户端在首次渲染后读取会话。服务器已知的身份应在页面数据中一同返回。
- 虚假的空状态： 在查询解析之前的一帧显示“未找到结果”，因为零行数据同时表示“加载中”和“为空”。
- 设计标记被替换为外观相似的标记， 在某一个主题中显着不同。
- 硬编码标签， 而其他四个调用点从共享目录读取相同标签。
- 打开时导致页面崩溃的菜单， 因为子组件依赖不存在的父组件。手动点击两次都未发现，因为没人打开过该菜单。
- 规格项被静默跳过， 另一项因合理原因被删除但未留下文档。任何偏离设计之处都需要注明原因。
- 自相矛盾的对话框， 通过查看截图发现：通知显示“所有座位已占用”，而旁边的页脚仍然显示“剩余2个座位”。