agentsclimarketplace

Swift testing expert

Skill AvdLee/Swift-Testing-Agent-Skill/swift-testing-expert

An agent skill focused entirely on Swift Testing, helping you write better tests, migrate from XCTest, improve test architecture, and adopt modern Swift testing patterns with confidence.

Install
npx -y skills add AvdLee/Swift-Testing-Agent-Skill --skill swift-testing-expert

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

4.8 KB, as published. Nobody here has run it

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)

  1. 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.
  2. Treat #expect as the default assertion and use #require when subsequent lines depend on a prerequisite value.
  3. Default to parallel-safe guidance. If tests are not isolated, first propose fixing shared state before applying .serialized.
  4. Prefer traits for behavior and metadata (.enabled, .disabled, .timeLimit, .bug, tags) over naming conventions or ad-hoc comments.
  5. Recommend parameterized tests when multiple tests share logic and differ only in input values.
  6. Use @available on test functions for OS-gated behavior instead of runtime #available checks inside test bodies; never annotate suite types with @available.
  7. Keep migration advice incremental: convert assertions first, then organize suites, then introduce parameterization/traits.
  8. 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
  • Default parallel execution, .serialized, isolation strategy -> references/parallelization-and-isolation.md
  • Test speed, determinism, and flakiness prevention -> references/performance-and-best-practices.md
  • Async waiting and callback bridging -> references/async-testing-and-waiting.md
  • XCTest coexistence and migration workflow -> references/migration-from-xctest.md
  • Test navigator/report workflows and diagnostics -> references/xcode-workflows.md
  • Index and quick navigation -> references/_index.md

Common pitfalls -> next best move

  • Repetitive testFooCaseA/testFooCaseB/... methods -> replace with one parameterized @Test(arguments:).
  • Failing optional preconditions hidden in later assertions -> try #require(...) then assert on unwrapped value.
  • Flaky integration tests on shared database -> isolate dependencies or in-memory repositories; use .serialized only as a transition step.
  • Disabled tests that silently rot -> prefer withKnownIssue for temporary known failures to preserve signal.
  • Unclear failure values for complex types -> conform type to CustomTestStringConvertible for focused test diagnostics.
  • Test-plan include/exclude by names -> use tags and tag-based filters instead.

Verification checklist

  • Confirm each test has a single clear behavior and expressive display name when needed.
  • Confirm prerequisites use #require where failure should stop the test.
  • Confirm repeated logic is parameterized instead of duplicated.
  • Confirm tests are parallel-safe or intentionally serialized with rationale.
  • Confirm async code is awaited and callback APIs are bridged safely.
  • Confirm migration keeps unsupported XCTest-only scenarios on XCTest.

References

  • references/_index.md
  • references/fundamentals.md
  • references/expectations.md
  • references/traits-and-tags.md
  • references/parameterized-testing.md
  • references/parallelization-and-isolation.md
  • references/performance-and-best-practices.md
  • references/async-testing-and-waiting.md
  • references/migration-from-xctest.md
  • references/xcode-workflows.md

Gives 0 of the 12 instructions most test skills give

Counted across 964 of the 1,571 authors here whose files we hold, read 2026-08-06

  • close the browser when donein 55 of 964, across 12 files
  • wait for network idle statein 51 of 964, across 6 files
  • launch chromium in headless modein 49 of 964, across 6 files
  • use descriptive selectors for elementsin 49 of 964, across 6 files
  • run provided scripts with help flag firstin 49 of 964, across 6 files
  • add appropriate explicit waitsin 48 of 964, across 5 files
  • use bundled scripts as black boxesin 46 of 964, across 3 files
  • do not read script source codein 46 of 964, across 3 files
  • use sync playwright for scriptsin 46 of 964, across 3 files
  • inspect dom before executing actionsin 46 of 964, across 3 files
  • run the full test suitein 36 of 964, across 34 files
  • write the failing test firstin 25 of 964, across 18 files

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.