Expert guidance for Swift Testing: test structure, #expect/#require macros, traits and tags, parameterized tests, test plans, parallel execution, async waiting patterns, and XCTest migration.
All-time #2980Trending #3425First seen Feb 12, 2026
Expert guidance for Swift Testing: test structure, #expect/#require macros, traits and tags, parameterized tests, test plans, parallel execution, async waiting patterns, and XCTest migration.
Use when writing new Swift tests, modernizing XCTest suites, debugging flaky tests, or improving test quality and maintainability in Apple-platform or Swift server projects.
Similar popular skills
Related neighbors and high-traction skills in the same topics — useful to compare before installing.
Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.
Claude CodeNot declared
CursorNot declared
CodexNot declared
GitHub CopilotNot declared
WindsurfNot declared
Gemini CLINot declared
ClineNot declared
OpenCodeNot declared
Repository health
Stars446
LicenseLICENSE
Default branchmain
Open issues1
Status
Active
Package contents
Files included with this skill beyond the listing page.
skill mdSKILL.md4,908 B
docsSUMMARY.md3,952 B
History
First seen on skills.sh
First recorded snapshot · 4,700 installs
SKILL.md
Swift Testing
Overview
Use this skill to write, review, migrate, and debug Swift tests with modern Swift Testing APIs. Prioritize readable tests, robust parallel execution, clear diagnostics, and incremental migration from XCTest where needed.
Agent behavior contract (follow these rules)
Prefer Swift Testing for Swift unit and integration tests, but keep XCTest for UI automation (XCUIApplication), performance metrics (XCTMetric), and Objective-C-only test code.
Treat #expect as the default assertion and use #require when subsequent lines depend on a prerequisite value.
Default to parallel-safe guidance. If tests are not isolated, first propose fixing shared state before applying .serialized.
Prefer traits for behavior and metadata (.enabled, .disabled, .timeLimit, .bug, tags) over naming conventions or ad-hoc comments.
Recommend parameterized tests when multiple tests share logic and differ only in input values.
Use @available on test functions for OS-gated behavior instead of runtime #available checks inside test bodies; never annotate suite types with @available.
Keep migration advice incremental: convert assertions first, then organize suites, then introduce parameterization/traits.
Only import Testing in test targets, never in app/library/binary targets.
First 60 seconds (triage template)
Clarify the goal: new tests, migration, flaky failures, performance, CI filtering, or async waiting.
Collect minimal facts:
- Xcode/Swift version and platform targets - Whether tests currently use XCTest, Swift Testing, or both - Whether failures are deterministic or flaky - Whether tests access shared resources (database, files, network, global state)
Branch quickly:
- repetitive tests -> parameterized tests - noisy or flaky failures -> known issue handling and test isolation - migration questions -> XCTest mapping and coexistence strategy - async callback complexity -> continuation/await patterns
Routing map (read the right reference fast)
Test building blocks and suite organization -> references/fundamentals.md
#expect, #require, and throw expectations -> references/expectations.md
Traits, tags, and Xcode test-plan filtering -> references/traits-and-tags.md
Parameterized test design and combinatorics -> references/parameterized-testing.md