
Swift Testing
Migrate or author iOS unit tests with Apple’s Swift Testing macros while keeping XCTest only where UI tests still require it.
Overview
swift-testing is an agent skill for the Ship phase that reviews XCTest-to-Swift Testing migration plans and emits corrected patterns for suites, fixtures, availability, and assertions.
Install
npx skills add https://github.com/dpearson2699/swift-ios-skills --skill swift-testingWhat is this skill?
- Rejects XCTestCase inheritance for migrated unit suites in favor of @Test functions or suites
- Maps XCTAssert, XCTUnwrap, and XCTFail to #expect, #require, and Issue.record with correct semantics
- Places @available on individual @Test functions, not suite or container types
- Recommends isolated per-test fixtures instead of shared singleton mutable state
- Preserves XCTest targets for UI tests where Swift Testing cannot replace XCTest
Adoption & trust: 1.8k installs on skills.sh; 713 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your migration plan still inherits XCTestCase, shares mutable fixtures, and mis-maps XCTUnwrap to #expect everywhere.
Who is it for?
Indie iOS devs on Swift 5.9+ who want agent-reviewed migration steps before touching production test targets.
Skip if: Android or cross-platform test stacks, or greenfield apps with no XCTest legacy to reconcile.
When should I use this skill?
User asks to migrate, review, or write Swift Testing suites, map XCTest assertions, or validate coexistence with XCTest UI tests.
What do I get? / Deliverables
You get corrected Swift Testing structure with isolated fixtures, proper #require usage, UI tests still on XCTest, and a safe incremental coexistence story.
- Corrected migration guidance with Swift examples
- Assertion and fixture mapping checklist
Recommended Skills
Journey fit
How it compares
Focused Swift Testing migration review—not a generic ‘write unit tests’ prompt or Detox-style E2E skill.
Common Questions / FAQ
Who is swift-testing for?
Solo builders and small teams shipping SwiftUI or UIKit apps who need accurate Swift Testing guidance while XCTest UI suites remain in the same workspace.
When should I use swift-testing?
In Ship → testing when you plan or review an XCTest migration, debate #expect versus #require, or need availability annotations on individual tests for iOS 18 APIs.
Is swift-testing safe to install?
It is documentation-style procedural knowledge with no shell side effects; still review the Security Audits panel on this Prism page before adding any third-party skill to your agent.
SKILL.md
READMESKILL.md - Swift Testing
{ "skill_name": "swift-testing", "evals": [ { "id": 0, "prompt": "Review this migration plan from XCTest to Swift Testing: keep the XCTestCase subclass, convert setUp/tearDown into a shared singleton fixture, put @available on the whole suite type for iOS 18 APIs, replace every XCTest assertion with #expect including XCTUnwrap, keep XCTFail(\"missing user\") for guard-failure paths, and keep UI tests in the same target because Swift Testing can replace XCTest everywhere. They also want to know whether XCTest and Swift Testing can coexist during migration. Give corrected guidance with concise Swift examples where useful.", "expected_output": "A migration review that converts XCTestCase classes into Swift Testing suites or free functions, uses isolated per-test fixtures, puts availability on test functions rather than suite types, maps XCTAssert/XCTUnwrap/XCTFail to #expect/#require/Issue.record, and preserves XCTest for UI testing.", "files": [], "assertions": [ "Rejects keeping XCTestCase inheritance for migrated Swift Testing unit tests and uses @Test functions or suites instead.", "Recommends per-test fixture setup using suite init or isolated fixtures rather than shared singleton mutable state.", "States that @available belongs on individual @Test functions, not on suite types or containing types.", "Explains that not every XCTest assertion should become #expect and uses #require for required values or unwraps.", "Keeps XCUITest UI tests on XCTest rather than claiming Swift Testing replaces XCTest everywhere." ] }, { "id": 1, "prompt": "I'm targeting iOS 26 with Swift 6.3 and wrote Swift Testing samples using #expect(exitsWith: .failure) in an exit-test closure that reads a local expectedCode, Test.cancel() in a sync test that awaits a network check, Issue.record(severity: .warning), and Attachment(image, named:).record(). Review the samples for current API spelling, availability, platform support, which pieces are Swift 6.2/Xcode 26.0 versus Swift 6.3/Xcode 26.4-era APIs, and any code-shape fixes.", "expected_output": "An advanced Swift Testing review that uses processExitsWith for exit tests, notes exit testing availability and supported runtime targets, fixes async Test.cancel sample shape, notes Swift 6.3/Xcode 26.4 availability for warning severity and image attachments, and records images with Attachment.record(..., as:).", "files": [], "assertions": [ "Replaces stale #expect(exitsWith:) with #expect(processExitsWith:).", "States that exit testing requires Swift 6.2/Xcode 26.0 or newer and is not supported on iOS/tvOS/watchOS runtime targets.", "Mentions Swift 6.3 capture-list requirements when discussing captured parent-process values in exit tests.", "Marks the Test.cancel example async when it awaits work and explains Test.cancel requires Swift 6.3/Xcode 26.4 or newer.", "Uses Issue.record(..., severity: .warning) and image Attachment.record(..., named: ..., as: .png) with Swift 6.3/Xcode 26.4 availability." ] }, { "id": 2, "prompt": "Plan tests for a SwiftUI checkout flow: unit-test a price calculator, verify async coupon events, snapshot the checkout screen in dark mode and Dynamic Type, measure parser performance, and automate the login-to-checkout UI path. Which pieces should use Swift Testing, which should stay with XCTest or snapshot tooling, and how should the test files be organized during migration?", "expected_output": "A boundary-aware test plan that uses Swift Testing for unit and async behavior tests, confirmation for callback/event checks, XCTest/XCUITest for UI automation and performance measurement, snapshot tooling for visual regression, and allows mixed files during migration while preferring clear separation for maintainability.", "files": [], "assertions": [ "Uses Swift Testing for pur