Swift Testing Standards skill

Write XCTest cases, async tests, and organized test suites in Swift.

by HoangNguyen0403·MIT license·★ 569 Stars on the repo·GitHub ↗

Use now

Files of Swift Testing Standards

HoangNguyen0403/develop1 file shown
SKILL.md
Show the full text62 lines

Swift Testing Standards

Priority: P0 (CRITICAL)

Core Rule Anchors

  • [MOB-TEST-01] Tripartite Naming: Test functions must follow test_method_scenario_expectedBehavior or testMethod_scenario_expectedBehavior.
  • [MOB-TEST-02] State Invariant Rule: Assert state transitions and invariants; ban trivial state mirror tests.
  • [MOB-TEST-03] Entity Invariant & Codable Rule: Test calculations, validations, domain invariants, and non-trivial Codable serialization/parsing or error mapping; ban testing trivial getters or echo tests.
  • [MOB-TEST-04] Contract Testing Rule: Repositories and data sources must be tested for contract compliance and error mapping; ban 1:1 pass-through mock echoing.
  • [MOB-TEST-05] Bug-First Regression Lock: Every PR fixing a bug ticket or with title fix(...) must introduce a test reproducing the defect prior to the fix.

Write XCTest Cases

  • Standard Naming: Test functions must prefixed by 'test' ([MOB-TEST-01], e.g., func test_userLogin_whenValid_isSuccessful()).
  • Setup/Teardown: Use setUpWithError() and tearDownWithError() for environment management.
  • Assertions: Use specific assertions: XCTAssertEqual, XCTAssertNil, XCTAssertTrue, etc.

See implementation examples for XCTest setup/teardown, async tests, and UI test patterns.

Test Async Code

  • Async/Await: Mark test methods as async throws and use try await directly inside them.
  • Expectations: Use XCTestExpectation for callback-based async logic. Call expectation then fulfill() when done; then wait(for: [exp], timeout: 2.0) to block.
  • Timeout: Always set reasonable timeouts for expectations to avoid hanging CI.

Organize Test Suites

  • Unit Tests: Use protocols for dependencies and inject them via constructor (e.g., init(service: ServiceProtocol)). Focus on logic isolation using mocks/stubs.
  • UI Tests: Test user flows using XCUIApplication and accessibility identifiers.
  • Coverage: Coverage is diagnostic and project-configured; verify risk-weighted critical paths rather than padding code for an arbitrary percentage.

Anti-Patterns

  • [MOB-TEST-01..05] Violations: Ban vague names, trivial state mirrors, echo tests, 1:1 mock echoing, and unverified bug fixes.
  • No Thread.sleep: Use expectations or await.
  • No force unwrap in tests: Use XCTUnwrap() for better failure messages.
  • No assertion-free tests: A test that only runs code without asserting contract invariants is not a test.

References

Canonical response anchors

When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:

  • Inject them via constructor
  • Use protocols
  • prefixed by 'test'
1---
2name: swift-testing
3description: Write XCTest cases, async tests, and organized test suites in Swift. Use when writing XCTest cases, async tests, or organizing test suites in Swift.
4metadata:
5 triggers:
6 files:
7 - '**/*Tests.swift'
8 keywords:
9 - XCTestCase
10 - XCTestExpectation
11 - XCTAssert
12---
13# Swift Testing Standards
14 
15## **Priority: P0 (CRITICAL)**
16 
17## Core Rule Anchors
18 
19- **`[MOB-TEST-01]` Tripartite Naming**: Test functions must follow `test_method_scenario_expectedBehavior` or `testMethod_scenario_expectedBehavior`.
20- **`[MOB-TEST-02]` State Invariant Rule**: Assert state transitions and invariants; ban trivial state mirror tests.
21- **`[MOB-TEST-03]` Entity Invariant & Codable Rule**: Test calculations, validations, domain invariants, and non-trivial `Codable` serialization/parsing or error mapping; ban testing trivial getters or echo tests.
22- **`[MOB-TEST-04]` Contract Testing Rule**: Repositories and data sources must be tested for contract compliance and error mapping; ban 1:1 pass-through mock echoing.
23- **`[MOB-TEST-05]` Bug-First Regression Lock**: Every PR fixing a bug ticket or with title `fix(...)` must introduce a test reproducing the defect prior to the fix.
24 
25## Write XCTest Cases
26 
27- **Standard Naming**: Test functions must prefixed by 'test' (`[MOB-TEST-01]`, e.g., `func test_userLogin_whenValid_isSuccessful()`).
28- **Setup/Teardown**: Use `setUpWithError()` and `tearDownWithError()` for environment management.
29- **Assertions**: Use specific assertions: `XCTAssertEqual`, `XCTAssertNil`, `XCTAssertTrue`, etc.
30 
31See [implementation examples](references/implementation.md) for XCTest setup/teardown, async tests, and UI test patterns.
32 
33## Test Async Code
34 
35- **Async/Await**: Mark test methods as `async throws` and use `try await` directly inside them.
36- **Expectations**: Use `XCTestExpectation` for callback-based async logic. Call `expectation` then `fulfill()` when done; then `wait(for: [exp], timeout: 2.0)` to block.
37- **Timeout**: Always set reasonable timeouts for expectations to avoid hanging CI.
38 
39## Organize Test Suites
40 
41- **Unit Tests**: Use protocols for dependencies and inject them via constructor (e.g., `init(service: ServiceProtocol)`). Focus on logic isolation using mocks/stubs.
42- **UI Tests**: Test user flows using `XCUIApplication` and accessibility identifiers.
43- **Coverage**: Coverage is diagnostic and project-configured; verify risk-weighted critical paths rather than padding code for an arbitrary percentage.
44 
45## Anti-Patterns
46 
47- **`[MOB-TEST-01..05]` Violations**: Ban vague names, trivial state mirrors, echo tests, 1:1 mock echoing, and unverified bug fixes.
48- **No Thread.sleep**: Use expectations or await.
49- **No force unwrap in tests**: Use `XCTUnwrap()` for better failure messages.
50- **No assertion-free tests**: A test that only runs code without asserting contract invariants is not a test.
51 
52## References
53 
54- [XCTest Patterns & Async Tests](references/implementation.md)
55 
56## Canonical response anchors
57 
58When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:
59- Inject them via constructor
60- Use protocols
61- prefixed by 'test'
62 

Discussion

Alternatives

`expo-overview` — router & shared rules for Expo / EASEntry point and router for every Expo or EAS task. Load this skill first — before writing code and before choosing another expo-* / eas-* skill — when the request, PRD, or spec mentions Expo, EAS, Expo Go, or an expo-* package, or the project has an `expo` dependency in `package.json`. Within that gate it also covers app specs and designs to implement (tabs, stacks, maps, lists, navigation, building from a screenshot), and phrasings like 'implement a mobile app', 'make my app look native', 'add navigation', 'fetch some data', 'upgrade my SDK', 'add Expo to my existing native app', 'ship to the App Store', or 'I'm new to Expo, where do I start'. A fully specified request (SDK pinned, libraries named, layout given) still routes through here — the shared setup rules still apply. Do NOT load it when neither signal is present: a bare React Native project with no `expo` dependency is not Expo work. Detects the real goal, routes to the right expo-* / eas-* skill, and owns the shared setup rules.Coding · MITAdd an App Clip to an Expo AppAdd an iOS App Clip target to an Expo app. Use when the user mentions App Clip, AASA, apple-app-site-association, appclips, smart app banner, or wants to ship a lightweight iOS Clip invoked from a URL alongside their parent app.Coding · MITApp Store DeploymentBuild and submit iOS and Android apps with EAS to TestFlight, the App Store, or Google Play. Supports Expo and other React Native projects, plus existing native apps. Use for eas.json setup, release pipelines, signing, app versions and build numbers, store submissions, and listing metadata. For Expo websites and API routes, use eas-hosting; for adding React Native screens to a native app, use expo-brownfield.Coding · MITDesigning with SleekUse when the user wants to design a mobile app or UI screens, when they mention their Sleek (sleek.design) projects, or when implementing Sleek designs in code (HTML, React Native, SwiftUI).Coding · MIT