SwiftUI 视图把状态、环境、布局和平台控件组合在一起，因此“测试 View”不是一种测试。最稳定的策略是按问题分层：纯逻辑用 Swift Testing 快速覆盖，少量渲染状态接受视觉回归检查，真实导航、输入与系统集成使用 XCTest UI 测试。每层只证明它擅长的事情，避免用大量端到端脚本验证一个简单条件判断。

先把决定从 body 中提取出来

折扣文本、按钮是否可用、错误映射和排序规则若埋在 body 里，只能通过渲染间接验证。把它们做成值类型或纯函数，视图只消费结果：

struct CheckoutPresentation: Equatable {
    let total: String
    let canSubmit: Bool
    let message: String?
}

func present(_ state: CheckoutState, currency: Currency) -> CheckoutPresentation {
    CheckoutPresentation(
        total: currency.format(state.total),
        canSubmit: state.items.isEmpty == false && state.isSubmitting == false,
        message: state.error.map(userFacingMessage)
    )
}

用 Swift Testing 为状态组合写参数化测试，直接比较语义结果。这些测试不需要启动模拟器，也不会因按钮圆角变化失败。异步模型使用可控 clock、fake service 和明确 cancellation，不能靠真实 sleep 等待 UI“应该更新”。

组件测试关注语义状态

小型视图需要覆盖加载、空数据、错误、成功、权限受限和极端文本，而不是只测理想路径。依赖通过 initializer 或 environment 注入，日期、locale、size category 和 color scheme 固定。测试装配器可以集中构造这些状态，避免每个文件重复一套不完整 mock。

SwiftUI 没有要求每个 View 都暴露内部层级。优先断言用户可感知的标签、按钮状态和操作结果，不要依赖私有 modifier 顺序。可访问性标识只给真正需要稳定定位的元素，并使用领域名称；给每个容器编号会把实现细节变成测试 API。

快照用于视觉合同，不用于所有行为

快照适合发现一个关键组件的间距、换行或主题意外改变，但基线必须固定设备、OS、语言、字体、外观和动画状态。将矩阵限制在高价值组合，例如核心卡片的浅/深色与大字体。若每个页面、每种状态和每台设备都生成图片，系统补丁会带来难以审查的海量差异。

项目不必绑定某个第三方快照库才能采用原则：稳定宿主、确定数据、像素或结构比较、人工审核差异。更新基线属于代码审查，不是测试失败后的自动动作。截图通过也不能证明按钮可点击、VoiceOver 顺序正确或数据真的保存。

UI 测试覆盖跨边界旅程

XCTest UI 测试适合登录后创建项目、处理深层链接、恢复失败、系统权限与多页面导航等真实旅程。选择少量最重要流程，每一步通过可访问性角色和稳定标识定位。测试数据由启动参数或本地测试服务器提供，避免共享线上账户和依赖公网状态。

等待应针对可观察条件，例如进度消失或结果出现，而不是固定睡眠。失败时保存截图、可访问性层级、应用日志和测试数据标识。脚本要能区分产品错误、测试数据错误与系统弹窗阻塞，否则“重跑通过”会掩盖问题。

无障碍是独立验收维度

动态字体、VoiceOver 标签、点击区域、对比度和 Reduce Motion 不能由普通逻辑测试完全证明。自动检查可以发现缺少标签和部分点击问题，人工探索仍需覆盖实际阅读顺序与含义。快照矩阵至少包含一个辅助字体尺寸，但不要把视觉相似误认为可用性。

建立清楚的失败归属

提交时运行纯逻辑和快速组件测试；合并前运行代表性快照；端到端套件可按关键流程与夜间矩阵分组。统计失败率和耗时，隔离不稳定测试时必须创建修复责任和期限，不能永久忽略。测试层越高，数量应越少、诊断信息越丰富。

结论

SwiftUI 测试的目标不是最大化 UI 测试数量，而是把风险放到成本最低且信号最清楚的层。纯函数证明决定，组件状态证明呈现合同，快照保护少量视觉边界，XCTest UI 证明跨系统旅程，再用无障碍检查补上真实使用。这样的组合比“一切都截图”更快，也比“一切都端到端”更容易维护。