Android Compose 语义与界面测试

摘要：Compose 界面测试应围绕用户能看见和操作的语义编写，而不是依赖脆弱的视图层级。本文介绍语义节点、状态等待和交互验证。

一、测试用户可感知行为

用户通过文字、角色、可点击状态和选中状态理解界面。测试优先查找这些语义属性，避免依赖组合函数数量或内部节点顺序。实现重构后，只要用户行为没变，测试就不该全部失效。

重要控件应有准确且唯一的可访问名称。装饰内容不应污染语义树，复合控件则应暴露清楚的整体操作和状态。

二、选择稳定断言

用户能看到的文字适合用来验证内容，测试标记适合没有稳定文字的控件。标记应说明控件用途，而不是临时布局编号。

测试遇到找不到节点时，先检查语义树和合并行为，再决定是否需要补充语义。无意义地增加多个标记会让界面维护更困难。

三、验证完整交互

表单测试覆盖正常输入、格式错误、加载中禁用和提交后的反馈。点击动作不只检查回调被调用，还应确认用户看到的状态变化正确。

单个组件测试使用假状态持有者或回调，不必加载整个应用依赖图。跨页面流程另由少量端到端测试覆盖。

四、等待异步状态

异步变化应通过条件等待，不要用固定睡眠猜测请求何时完成。使用确定性假仓库控制加载、成功和失败时机，测试更容易复现。

动画测试可以控制时钟或关闭不相关动画，避免受设备速度影响。涉及加载状态时，也要验证取消和重复提交。

五、按风险分层测试

纯状态转换适合单元测试；单个可组合控件适合轻量界面测试；跨页面完整流程适合少量端到端测试。层级越高，准备和运行成本通常越大。

关键流程还应覆盖系统返回、键盘输入和窄屏布局，但不必在每个控件测试里重复验证整套导航。

六、避免脆弱选择器

不要依赖同类节点的第几个元素、固定坐标或像素截图验证普通业务状态。列表项目通过稳定内容或业务身份查找。截图比较适用于视觉回归目标明确且环境可控的场景。

合理标签、角色和状态同时帮助辅助技术和自动化测试，测试可更接近真实操作。

七、总结

Compose 测试以语义和可观察状态为中心，用确定性数据源控制异步过程，并按风险分配不同测试层级。这样既能保护用户行为，也允许界面内部结构持续调整。