折断

要解决什么问题

iOS 团队在 UI 重构、多语言与多机型发布后，常见痛点是：XCUITest 靠文案或坐标定位，一改版就红；PR 里只有 xcodebuild test 日志，失败时拿不到可复现的界面证据；App Store 截图又要单独维护一套脚本，和回归测试用的标识符对不上。

Snap 的定位是 纯 iOS 的 XCUITest 与截图专家：在 Native / Builder 交付带 UI 的功能后，把「可测的标识符 + 可跑的流程 + 可归档的结果」补齐，而不是去写 SwiftUI 业务代码或跨平台 Appium 套件。

技能如何工作

核心信条可以概括为：先是标识符，再是快照。典型路径对应文档里的 SCOPE → IDENTIFY → AUTHOR → STABILIZE → CAPTURE → REPORT：

• IDENTIFY：审计 accessibilityIdentifier，约定 screen.section.element 分类；缺标识符时先回流 Native，而不是写脆弱的 label 查询。
• AUTHOR / STABILIZE：用 Screen Object 封装 XCUIElementQuery；同步用 XCTNSPredicateExpectation + wait(for:timeout:)，用 launchArguments / launchEnvironment 注入启动态，避免 Thread.sleep 和「先点进设置再测」式夹具。
• CAPTURE：失败用 XCTAttachment.screenshot（.lifetime = .keepAlways）留证；App Store 走 fastlane snapshot，与回归共用同一测试目标与页面对象，截图跑在独立 Scheme，避免拖慢 PR CI。
• REPORT：以 .xcresult 为准，用 xcresulttool 解析附件与统计；需要真机矩阵时再走 BrowserStack / Sauce / Device Farm 的 .xctestrun 上传。

子命令可按意图切换：xcuitest、identifier、screenshot、appstore、page-object、ci、farm、xcresult。

边界与注意点

• 范围：仅 Xcode + Swift/SwiftUI/UIKit + XCUITest；Android UI 测试交给 Voyager，无 UI 的单元/集成层交给 Radar。
• 截图分工：XCUITest 截图是证据，不是像素级门禁；视图基线用 swift-snapshot-testing，或下游视觉工具，需先澄清意图。
• 反模式：坐标点击作主策略、把 Snapshot.images/ 提交主分支、与冒烟套件同一 Scheme 跑 fastlane 快照，都会放大 flake 与 CI 成本。