testing_skill

This skill generates Swift test data factories and builders to reduce boilerplate and speed up test setup with reusable fixtures.
  • 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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational