ios-testing-skill

adilkalam's avatarfrom adilkalam

Skill describing modern iOS testing patterns: Swift Testing vs XCTest, XCUITest best practices, and OS 4.1 expectations for coverage and flakiness.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 24, 2025
[Testing and QA]

When & Why to Use This Skill

This Claude skill provides comprehensive guidance for modern iOS testing, facilitating the transition from XCTest to the Swift Testing framework. It offers standardized patterns for unit, integration, and UI testing (XCUITest), alongside specialized strategies for verifying SwiftData models and SwiftUI atom-based state management to ensure high code coverage and minimal flakiness.

Use Cases

  • Migrating legacy XCTest suites to the modern Swift Testing framework using @Test and #expect macros while maintaining coverage parity.
  • Implementing robust UI tests with XCUITest using page objects, accessibility identifiers, and async-safe waiting strategies.
  • Testing SwiftData persistence layers using in-memory ModelContainers to verify relationship cascades and unique constraints without side effects.
  • Isolating and unit testing SwiftUI state management by using AtomTestContext and mocking dependencies with atom overrides.
  • Establishing automated quality gates to detect non-deterministic tests and flakiness risks like sleep-based waits in CI/CD pipelines.
nameios-testing-skill
description>
Skill describing modern iOS testing patternsSwift Testing vs XCTest,

iOS Testing Skill – Swift Testing, XCTest, XCUITest

This skill centralizes iOS testing guidance so that testing agents and gates can stay lean while following consistent patterns.

It is used by:

  • ios-testing-specialist
  • ios-ui-testing-specialist
  • ios-verification
  • ios-architect / ios-builder when planning or implementing tests.

Core Concepts

  • Swift Testing vs XCTest

    • Prefer Swift Testing for Swift 6+ targets where available.
    • Maintain parity when migrating from XCTest; do not regress coverage.
    • Use @Test and #expect/#require with clear naming and tagging.

  • Unit vs Integration vs UI

    • Unit tests: small, isolated; no network/DB unless explicitly integration.
    • Integration tests: limited external dependencies; deterministic configs.
    • UI tests (XCUITest): page objects, accessibility identifiers, async-safe waits.

  • Testing SwiftData Models

    • Use ModelContainer with isStoredInMemoryOnly: true for tests
    • Test @Relationship cascade deletes verify dependent data is removed
    • Verify FetchDescriptor queries return expected results
    • Use @MainActor for SwiftData operations in async tests
    • Test unique constraints (@Attribute(.unique)) enforce uniqueness

  • Testing SwiftUI Atoms

    • Use AtomTestContext for isolated atom testing
    • Override atoms with .override() for dependency injection
    • Test computed atoms (ValueAtom) derive correct values from dependencies
    • Verify StateAtom mutations trigger dependent atom updates
    • Test atom dependency graphs with graphDescription()

Context7 Libraries

Agents using this skill MAY consult:

  • os2-ios-testing

    • Swift Testing patterns and examples,
    • XCTest/XCUITest structure and migration guidance,
    • Flakiness mitigation strategies and CI integration tips.

  • /websites/developer_apple_swiftdata (via Context7)

    • In-memory ModelContainer patterns for testing
    • Testing @Relationship cascade rules
    • Async/await patterns with @MainActor
    • FetchDescriptor query testing

  • /ra1028/swiftui-atom-properties (via Context7)

    • AtomTestContext for isolated state testing
    • Mocking atoms with .override() for dependency injection
    • Testing atom dependency graphs
    • Verifying computed atoms derive correct values

Usage Pattern

  1. When designing a test strategy:

    • Decide which layers to cover (unit/integration/UI),
    • Choose Swift Testing vs XCTest based on project/tooling,
    • Define critical paths, error cases, and edge cases up front.

  2. When implementing tests:

    • Keep tests deterministic and fast by default,
    • Use tags/traits for slow/critical suites,
    • Structure UI tests around page objects and accessibility identifiers.

  3. When testing data persistence (SwiftData):

    • Always use in-memory ModelContainer in tests
    • Test cascade deletes remove dependent data
    • Verify unique constraints throw on duplicates
    • Test relationship integrity (one-to-many, many-to-one)
    • Use @MainActor for async SwiftData tests

  4. When testing state management (Atoms):

    • Use AtomTestContext to isolate atom behavior
    • Override dependency atoms with .override() for mocking
    • Test computed atoms recalculate when dependencies change
    • Verify StateAtom mutations propagate to watchers
    • Test atom cleanup when watchers are removed

  5. When acting as a gate (verification/quality):

    • Look for coverage of happy paths + failure/edge states,
    • Call out flakiness risks (sleep-based waits, environment dependence),
    • Recommend incremental improvements, not full rewrites, unless required.
    • Verify SwiftData tests use in-memory containers
    • Verify Atom tests use AtomTestContext, not real app state

This skill ensures iOS agents talk about testing in a consistent way and know when to consult context7 for deeper patterns and examples.