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.
SkillScore95Maintained
Automatic
◆QA & Test Engineering pack
Last verified 8/20/2026
What it changes
Passed 21 of 22 test cases with the skill, and 19 of 22 without it.
Without skill86%
With skill95%
Checks it passed that the model alone missed
Uses the Swift Testing framework rather than XCTestCase
Advises against placing available attributes on suite types
Recommends placing available attributes on individual test functions
and 1 more in the full report
3 fixed18 passed either way0 still failing1 broke
Pass-rate lift
+9 pp
Tokens
+15%
Agent turns
0%
Response time
-36%
Model gemini-3.6-flashMeasured 8/20/2026v121 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
An engineer added `@available(iOS 18, *)` to a test suite struct containing ten test functions. Is this the standard approach for OS-gated tests in Swift testing, or should this be refactored?
What was checked, without and with the skill
Checked
Without skill
With skill
Advises against placing available attributes on suite types
Missed
Passed
Recommends placing available attributes on individual test functions
Missed
Passed
case-09 · gemini-3.6-flash · 8/20/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md74 lines11 files
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