Swift Testing Pro skill
Paul Hudson's Swift Testing skill: parameterized tests, confirmations, exit tests and a move from XCTest to the new framework
- 475 ★ on the repository
- Last commit
- MIT
Minimal access
Why this level
- The skill is text rules and references that run nothing themselves, although the agent edits your tests following them.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/swift-testing-proDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewMinimal accessThe tool runs nothing and makes no network calls.
- The skill is text rules and references that run nothing themselves, although the agent edits your tests following them.
This is third-party code. Review the repository files before installing.
What it does
Swift Testing Pro is a skill that writes and reviews tests in Swift Testing using modern APIs. It targets mistakes agents repeat because they learned on XCTest: an `XCTestCase` class instead of a struct, `setUp` instead of `init`, a redundant `@Suite` above every set and an exclamation mark inside `#expect`. Five reference files cover core rules, test hygiene and hidden dependencies, async tests with `confirmation()` and time limits, Swift 6.2 novelties and the move from XCTest. The novelties include backtick test names, range-based confirmations, test scopes, exit tests and attachments. The skill treats the user's installed toolchain as the main source, because Apple's documentation for fresh APIs is sometimes stale. It suggests new techniques but by default does not introduce them into a project that does not use them yet. For a review request, the result comes as a per-file list: line, broken rule, a before and after fix, then a summary by importance.
Who it is for. iOS and macOS developers who write and review Swift Testing tests with Claude Code, Codex, Cursor or Gemini CLI.
Good fit when
- A project moves off XCTest, and the tests must be converted to `@Test` and `#expect` without losing meaning.
- An agent wrote a test class with `setUp`, and it must be brought to idiomatic form.
- A dozen similar tests collapse into one parameterized test.
- Code with a known bug is wrapped in `withKnownIssue` so the test stops failing until the bug is fixed.
Not a fit when
- App UI is under test: Swift Testing does not support UI tests, and XCTest remains there.
- The deployment target runs a Swift below 6.2: some techniques, such as backtick test names, require 6.2.
- The review is about SwiftUI, SwiftData or concurrent code: the author has separate skills for those.
Example request
Convert the tests in the Tests/ folder from XCTest to Swift Testing and merge similar checks into parameterized tests.Limitations
The skill targets Swift 6.2 and newer, and on an older toolchain some advice will not work. It does not cover UI tests. The author kept it short on purpose and does not retell Swift Testing basics the model already knows, so it is no substitute for a tutorial. Calling it depends on the agent: `/swift-testing-pro` in Claude Code, `$swift-testing-pro` in Codex, and elsewhere the skill is picked up by description or by the phrase "use the Swift Testing Pro skill".
How to disable. In Claude Code run `/plugin uninstall swift-testing-pro@swift-testing-agent-skill`. Remove a skill installed through `npx skills` with the same CLI or by hand from the agent's skills directory.
FAQ
How do I install the skill in Claude Code?
Run `/plugin marketplace add twostraws/Swift-Testing-Agent-Skill`, then `/plugin install swift-testing-pro@swift-testing-agent-skill`. For Codex, Gemini and Cursor, use `npx skills add` with the `--skill swift-testing-pro` flag; the CLI asks which agents and which scope to install for.
How do I call the skill for a partial review?
Add the task to the name: `/swift-testing-pro Make sure my tests are fully parameterized` in Claude or `$swift-testing-pro Add exit tests to my test suites` in Codex. An ordinary phrase works too, such as "use the Swift Testing Pro skill to find weak tests".
Does every suite need `@Suite`?
No, any type with `@Test` methods already counts as a suite. `@Suite` is needed when a suite gets a name or traits, for example `@Suite(.tags(.networking))`.
Why is `#expect(!isLoggedIn)` discouraged?
The exclamation mark breaks how the macro parses the expression, and a failure report becomes useless. The skill requires `#expect(isLoggedIn == false)`.
Is the skill suitable for UI tests?
No, Swift Testing does not support such tests, and XCTest remains for them. The skill reminds the agent of this explicitly.
Discussion
No questions or reviews yet.
Related
SkillsSwift Testing Agent Skill
swift-testing-agent-skill
A Swift Testing skill from Antoine van der Lee: the new APIs, migration from XCTest, parameterized tests and flat tests. For Claude Code and other agents
A skill for React Native Testing Library tests: queries, userEvent, async patterns and the differences between versions 13 and 14
A skill that guides Claude Code and Codex through writing and fixing pytest API tests with a real-run verification loop.
57 reference files on Playwright tests in TypeScript: the agent pulls the one that fits the task, from locators to CI sharding
Guides for agents writing and fixing Playwright tests, with advice on locators, waiting and diagnosing CI failures
The noqa-testing skill teaches an agent to test iOS and Android: read the screen, tap, write cases and run them on a real phone
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Repository stars | Main difference |
|---|---|---|---|
| Swift Testing Pro (this card) | no | 475 | |
| Swift Testing Agent Skill | no | 479 | a skill by Antoine van der Lee with new APIs, XCTest migration and flat tests; this one holds Paul Hudson's rules against agent mistakes, with separate references on async tests and Swift 6.2 novelties |
| Swift Concurrency Pro | no | 582 | a skill by the same author for concurrent Swift code; this one reviews tests only |
README in short
The author wrote a book on Swift Testing and updates it as the language evolves, and the skill's rules grew out of that material. Contributors are told to keep things short and not repeat what models already know, so the user's tokens are not wasted.
README badge
Original SKILL.md
--- name: swift-testing-pro description: Writes, reviews, and improves Swift Testing code using modern APIs and best practices. Use when reading, writing, or reviewing projects that use Swift Testing. license: MIT metadata: author: Paul Hudson version: "1.0" --- Write and review Swift Testing code for correctness, modern API usage, and adherence to project conventions. Report only genuine problems - do not nitpick or invent issues. Review process: 1. Ensure tests follow core Swift Testing conventions using `references/core-rules.md`. 1. Validate test structure, assertions, dependency injection, and other best practices using `references/writing-better-tests.md`. 1. Check async tests, confirmations, time limits, actor isolation, and networking mocks using `references/async-tests.md`. 1. Ensure new features like raw identifiers, test scopes, exit tests, and attachments are used correctly using `references/new-features.md`. 1. If migrating from XCTest, follow the conversion guidance in `references/migrating-from-xctest.md`. If doing partial work, load only the relevant reference files. ## Core Instructions - Target Swift 6.2 or later, using modern Swift concurrency. - As a Swift Testing developer, the user wants all new unit and integration tests to be written using Swift Testing, and they may ask for help migrating existing XCTest code to Swift Testing. - Swift Testing does *not* support UI tests – XCTest must be used there. - Use a consistent project structure, with folder layout determined by app features. Swift Testing evolves with each Swift release, so expect three to four releases each year, each introducing new features. This means existing training data you have will naturally be outdated or missing key features. This skill specifically draws upon the very latest Swift and Swift Testing code, which means it will suggest things you are not aware of. Treat the user’s installed toolchain as authoritative, but there's a fairly high chance Apple's *documentation* about the APIs will be stale, so treat them carefully. ## Output Format If the user asks for a review, organize findings by file. For each issue: 1. State the file and relevant line(s). 2. Name the rule being violated. 3. Show a brief before/after code fix. Skip files with no issues. End with a prioritized summary of the most impactful changes to make first. If the user asks you to write or improve tests, follow the same rules above but make the changes directly instead of returning a findings report.