testing_skill
- Swift
56
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
3 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill rshankras/claude-code-apple-skills --skill testing- SKILL.md3.4 KB
Overview
This skill generates test fixture factories for Swift models so creating sample data in tests requires zero boilerplate. It produces static fixture extensions, optional builder classes, sequence helpers, date helpers, and mock response factories to make tests deterministic and concise. The output is placed in test targets so production code stays untouched.
How this skill works
The skill scans source and test targets to discover model types (Identifiable, Codable, Sendable, @Model) and instances constructed in tests. It asks which factory style to generate (static fixtures, builder pattern, or both) and where to place them (test target extension or shared test helper). Then it produces Swift files with sensible defaults, named scenarios, collection generators, date helpers, and API response factories that integrate with your models' types.
When to use it
- When tests repeat identical setup code across cases
- When you need realistic sample data for unit or integration tests
- When tests are flaky due to Date() or nondeterministic values
- When you want readable one-line fixtures instead of long initializers
- When building many state-based or sequence-driven test cases
Best practices
- Keep factories in test targets via @testable import to avoid polluting production code
- Use fixed reference dates (not Date()) to avoid flaky tests
- Default UUIDs to UUID() and strings to descriptive placeholders
- Provide .fixture(...) for flexible overrides and .sample/.named for quick scenarios
- Generate sequence/fixtures(count:) helpers for loops and bulk tests
- Prefer static fixtures for simple models and builders for complex, stateful models
Example use cases
- Create a one-line Item.fixture(isFavorite: true) instead of repeating an initializer in every test
- Build complex objects with ItemBuilder().with(title: "X").favorited().build() in feature tests
- Generate deterministic dates via Date.testReference and Date.testDate(daysFromReference:) for scheduling tests
- Produce API response fixtures like APIResponse<[Item]>.success(items:) and .error() for network layer tests
- Create collections with Item.fixtures(count: 5) or Item.allStates for state coverage
FAQ
No. Factories are placed in test targets (extensions or test helper files) and use @testable import so production sources remain unchanged.
How do factories handle dates and UUIDs?
Dates default to a fixed test reference to prevent flakiness; UUIDs default to UUID() so each call is unique. Both behaviors can be overridden via fixture parameters.