xctest-patterns_skill

Overview

This skill provides expert guidance for XCTest decisions across iOS and tvOS projects. It helps choose test types, design test doubles (mock/stub/spy), avoid async and UI pitfalls, and set sensible coverage targets. Use it to shape a pragmatic, maintainable test strategy and to debug flaky tests.

How this skill works

The skill evaluates the testing goal and recommends the appropriate test layer (unit, integration, UI) and distribution within the test pyramid. It advises when to use stubs, spies, or mocks, prescribes async testing patterns (async/await, XCTestExpectation, Combine helpers), and flags anti-patterns to avoid. It also suggests coverage targets per layer and concrete patterns like structured mocks, test data builders, and publisher await helpers.

When to use it

• Designing or revising a test strategy for a new or existing feature
• Deciding whether to mock a dependency or use real implementation
• Debugging flaky tests caused by timing, shared state, or UI waits
• Choosing the right async testing approach for callbacks, async/await, or Combine
• Setting realistic coverage targets by layer (domain, services, view models)

Best practices

• Prefer unit tests for pure business logic; keep them fast and numerous
• Mock external I/O always; prefer real fast internal implementations for meaningful integration
• Verify only the observable behavior that matters for the test, not internal implementation details
• Use async test functions or XCTestExpectation — never sleep() or fire-and-forget Tasks
• Use accessibility identifiers and waitForExistence for UI tests instead of fixed delays

Example use cases

• Decide between a unit test and an integration test for a service that talks to a local cache and remote API
• Design a MockUserService that returns stubbed data and records call counts for verification
• Convert flaky UI tests that used Thread.sleep into robust waits using waitForExistence
• Write async tests for Combine publishers using an awaitPublisher helper on XCTestCase
• Set coverage targets: 90%+ for domain logic, ~85% for services, 70–80% for view models