关于 axiom-ios-testing
面向 iOS 开发者的测试路由技能，可按测试设计、可靠性、速度和执行需求，将问题引导至专门技能或 Agent。决策路径涵盖 Swift Testing、XCTest/XCUITest、异步测试和命令行工作流。
主要功能
- 01按需求路由测试问题
- 02指导选择 Swift Testing 或 XCTest
- 03分派异步与不稳定测试排查
- 04将命令行运行转交 test-runner
- 05涵盖 UI 自动化与测试审计
适用场景
- 01为新单元测试或 UI 测试选择方案
- 02查找间歇性 CI 失败的处理指引
- 03选择异步测试代码模式
- 04路由测试执行与结果分析
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/axiom-ios-testing确认已加载。
详细介绍
iOS 测试路由器
任何与测试相关的问题都必须使用此技能，包括编写测试、调试测试失败、加快测试速度，或选择测试方案。
适用场景
遇到以下情况时使用此路由器：
- 编写新的单元测试或 UI 测试
- Swift Testing 框架（@Test、#expect、@Suite）
- XCTest 或 XCUITest 问题
- 加快测试运行速度（不使用模拟器）
- 不稳定的测试（有时通过，有时失败）
- 可靠地测试异步代码
- 从 XCTest 迁移到 Swift Testing
- 测试架构决策
- 基于条件的等待模式
路由逻辑
此路由器会根据具体的测试需求调用专用技能：
1. 单元测试 / 快速测试 → swift-testing
触发条件：
- 编写新的单元测试
- Swift Testing 框架（
@Test、#expect、#require、@Suite） - 让测试在不使用模拟器的情况下运行
- 可靠地测试异步代码
withMainSerialExecutor、TestClock- 从 XCTest 迁移
- 参数化测试
- 标签和特征
- Host Application：None 配置
- Swift 包测试（
swift test） - 纯逻辑测试耗时超过 5 秒
- 希望采用能快速获得反馈的 TDD
为何选择 swift-testing：现代 Swift Testing 框架，支持并行执行、提供更好的异步支持，还能在不启动模拟器的情况下运行。
调用方式：阅读 axiom-swift-testing 技能
2. UI 测试 / XCUITest → ui-testing
触发条件：
- 录制 UI 自动化（Xcode 26）
- XCUIApplication、XCUIElement
- 不稳定的 UI 测试
- 测试在本地通过、在 CI 中失败
- 使用
sleep()或任意超时 - 基于条件的等待
- 跨设备测试
- 无障碍优先的测试
为何选择 ui-testing：XCUITest 需要模拟器，并且有确保可靠性的独特模式。
调用方式：阅读 axiom-ui-testing 技能
3. 不稳定的测试 / 竞态条件 → test-failure-analyzer（Agent）
触发条件：
- 测试在 CI 中随机失败
- 测试在本地通过、在 CI 中失败
- 不稳定的测试（有时通过，有时失败）
- Swift Testing 中的竞态条件
- 异步回调缺少
await confirmation - UI 测试缺少
@MainActor @Suite中存在共享可变状态- 测试单独运行时通过、一起运行时失败
为何选择 test-failure-analyzer：专用 Agent，可扫描 Swift Testing 中导致间歇性失败的模式。
调用方式：启动 test-failure-analyzer Agent
4. 异步测试模式 → testing-async
触发条件：
- 测试 async/await 函数
- 使用
confirmation测试回调（Swift Testing） - 使用
expectedCount处理多个回调 - 使用
@MainActor @Test测试 MainActor 代码 - 将 XCTestExpectation 迁移到 confirmation
- 并行测试执行相关问题
- 测试超时配置
为何选择 testing-async：专为 Swift Testing 框架中的异步代码提供的模式。
调用方式：阅读 axiom-testing-async 技能
5. 测试崩溃 / 环境问题 → xcode-debugging
触发条件：
- 测试在执行断言前崩溃
- 模拟器无法启动以运行测试
- 测试无限期挂起
- 出现“Unable to boot simulator”错误
- 全新测试运行与增量测试运行结果不同
为何选择 xcode-debugging：用于处理由环境问题而非测试逻辑导致的测试失败。
调用方式：阅读 axiom-xcode-debugging 技能
6. 从命令行运行 XCUITests → test-runner（Agent）
触发条件：
- 使用 xcodebuild 运行测试
- 解析 xcresult 捆绑包
- 导出失败截图/视频
- 代码覆盖率报告
- CI/CD 测试执行
为何选择 test-runner：专用 Agent，用于从命令行执行测试，并使用 xcresulttool 进行解析。
调用方式：启动 test-runner Agent
7. 闭环测试调试 → test-debugger（Agent）
触发条件：
- 自动修复失败的测试
- 调试持续失败的测试
- 运行 → 分析 → 修复 → 验证循环
- 需要反复迭代，直到测试通过
- 分析失败截图
为什么选择 test-debugger：自动执行运行测试、分析失败、提供修复建议并重新运行的循环。
调用方式：启动 test-debugger Agent
8. 录制 UI 自动化（Xcode 26）→ ui-recording
触发条件：
- 在 Xcode 中录制用户交互
- 为多配置回放制定测试计划
- 查看测试运行视频
- Xcode 26 录制工作流
- 改进录制的测试代码
为什么选择 ui-recording：专为 Xcode 26 的 Record/Replay/Review 工作流提供指南。
调用方式：阅读 axiom-ui-recording skill
9. 测试质量审计 → testing-auditor（Agent）
触发条件：
- 想要审计测试质量
- 查找不稳定测试模式（sleep 调用、共享可变状态）
- 加快测试执行速度
- 从 XCTest 迁移到 Swift Testing
- 检查测试是否存在 Swift 6 并发问题
为什么选择 testing-auditor：将测试覆盖情况与生产代码进行对照，检测不稳定模式和速度问题，找出未测试的关键路径（身份验证、支付、持久化），并评估整体测试健康状况。
调用方式：启动 testing-auditor Agent 或运行 /axiom:audit testing
10. 无需 XCUITest 的 UI 自动化 → simulator-tester + axe-ref
触发条件：
- 在没有测试目标的情况下自动化应用
- 使用 AXe CLI（点击、滑动、输入）
- 使用 describe-ui 查看无障碍树
- 在 XCUITest 之外快速实现自动化
- 通过脚本与模拟器交互
为什么选择 simulator-tester + axe-ref：AXe 可在无法使用 XCUITest 时，提供基于无障碍功能的 UI 自动化。
调用方式：启动 simulator-tester Agent（使用 axiom-axe-ref）
决策树
- 编写单元测试 / Swift Testing？→ swift-testing
- 编写 UI 测试 / XCUITest？→ ui-testing
- 测试 async/await 代码？→ testing-async
- 不稳定测试 / 竞态条件（XCUITest）？→ ui-testing
- 不稳定测试 / 竞态条件（Swift Testing）？→ test-failure-analyzer（Agent）
- 测试崩溃 / 环境不正确？→ xcode-debugging（通过 ios-build）
- 测试运行缓慢 / 想使用 swift test？→ swift-testing（策略 1：提取 Package）
- 从 CLI 运行测试 / 解析结果？→ test-runner（Agent）
- 自动修复失败的测试？→ test-debugger（Agent）
- 想要审计测试质量（不稳定模式、迁移）？→ testing-auditor（Agent）
- 录制 UI 交互（Xcode 26）？→ ui-recording
- 无需 XCUITest 实现自动化 / 使用 AXe CLI？→ simulator-tester + axe-ref
Swift Testing 与 XCTest 快速指南
| 需求 | 使用 |
|---|---|
| 单元测试（逻辑、模型） | Swift Testing |
| UI 测试（点击、滑动、断言屏幕） | XCUITest（XCTest） |
| 无需模拟器的测试 | Swift Testing + Package/Framework |
| 参数化测试 | Swift Testing |
| 性能测量 | XCTest（XCTMetric） |
| Objective-C 测试 | XCTest |
避免自我合理化
| 想法 | 事实 |
|---|---|
| “只是个简单的测试问题，不需要 skill。” | 正确的模式可以防止测试债务。swift-testing 提供可直接复制粘贴的解决方案。 |
| “我对 XCTest 已经足够熟悉了。” | 对于单元测试，Swift Testing 好得多。swift-testing 涵盖迁移相关内容。 |
| “测试运行缓慢，但没关系。” | 快速测试有助于实践 TDD。swift-testing 展示了如何在没有模拟器的情况下运行测试。 |
| “我会用 sleep() 修复不稳定的测试。” | sleep() 会让测试更慢，也更不稳定。ui-testing 提供了基于条件的等待模式。 |
| “以后再添加测试。” | 实现完成后再编写测试，容易遗漏边缘情况。swift-testing 让先编写测试变得简单。 |
示例调用
用户：“如何用 Swift 编写单元测试？” → 调用：axiom-swift-testing
用户：“我的 UI 测试在 CI 中不稳定” → 检查代码库：是否有 XCUIApplication/XCUIElement 模式？→ ui-testing → 检查代码库：是否有 @Test/#expect 模式？→ test-failure-analyzer
用户：“测试随机失败，有时通过，有时失败” → 调用：test-failure-analyzer（Agent）
用户：“测试在本地通过，但在 CI 中失败” → 调用：test-failure-analyzer（Agent）
用户：“如何测试异步代码，同时避免不稳定？” → 调用：testing-async
用户：“如何使用 Swift Testing 测试基于回调的 API？” → 调用：testing-async
用户：“Swift Testing 中与 XCTestExpectation 等效的是什么？” → 调用：testing-async
用户：“如何使用带有 expectedCount 的 confirmation？” → 调用：testing-async
用户：“我想让测试运行得更快” → 调用：axiom-swift-testing（策略 1：提取 Package）
用户：“我的单元测试需要 25 秒才能运行” → 调用：axiom-swift-testing（策略 1：提取 Package）
用户：“如何用 swift test 代替 xcodebuild test？” → 调用：axiom-swift-testing（快速测试章节）
用户：“我应该使用 Swift Testing 还是 XCTest？” → 调用：axiom-swift-testing（迁移章节）+ 本决策树
用户：“测试在执行任何断言之前就崩溃了” → 调用：axiom-xcode-debugging
用户：“运行我的测试并告诉我哪些失败了” → 调用：test-runner（Agent）
用户：“帮我修复这些失败的测试” → 调用：test-debugger（Agent）
用户：“解析我上次测试运行生成的 xcresult” → 调用：test-runner（Agent）
用户：“从我的测试中导出失败截图” → 调用：test-runner（Agent）
用户：“如何在 Xcode 26 中录制 UI 自动化？” → 调用：axiom-ui-recording
用户：“如何使用 test plans 进行多语言测试？” → 调用：axiom-ui-recording
用户：“不编写 XCUITests，也能自动化测试我的应用吗？” → 调用：simulator-tester（Agent）+ axiom-axe-ref
用户：“如何使用 AXe 点击按钮？” → 调用：axiom-axe-ref（通过 simulator-tester）
用户：“审查我的测试，找出质量问题”
→ 调用：testing-auditor Agent
用户：“我应该迁移到 Swift Testing 吗？”
→ 调用：testing-auditor Agent