swift-testing-expert
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.
What this skill does
# 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`
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.