test-contract_skill

This skill defines protocol contract tests in Swift to ensure every implementation passes identical behavioral tests.
  • 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 test-contract

  • SKILL.md9.0 KB

Overview

This skill generates reusable contract test suites for Swift protocols so every implementation can be validated against the same behavioral specification. Define the protocol contract once and produce generic tests that concrete implementations (real, mock, or AI-generated) must pass. It helps prevent regressions when swapping data stores, network clients, caches, or auth backends.

How this skill works

The skill inspects a protocol signature and extracts required methods, properties, and invariants, then maps each element to clear behavioral assertions (success, failure modes, edge cases, and invariants). It emits a generic, parameterizable Swift test suite (async-safe) that can be instantiated per implementation or run parametrically across implementations. Tests include CRUD, error paths, ordering, thread-safety considerations, and explicit invariants like count consistency.

When to use it

  • Designing a new protocol and needing a single source of truth for behavior
  • You have multiple implementations (in-memory, DB, cloud, mock) and must ensure parity
  • Swapping persistence layers (e.g., CoreData → SwiftData) or client implementations
  • Validating AI-generated or third-party implementations against your spec
  • Adding regression protection when evolving protocol contracts

Best practices

  • Write clear, minimal protocol docs describing expected side effects and invariants before generating tests
  • Cover success paths, common error cases, and boundary conditions for each method
  • Keep contract tests implementation-agnostic: use factory closures to create instances
  • Include invariants as explicit tests (e.g., count == fetchAll().count) and run them after mutations
  • Run contract suites in CI for every implementation and fail builds on divergence

Example use cases

  • Generate a DataStore contract suite covering save/fetch/delete/fetchAll and invariants, then run it against InMemory, SQLite, and Cloud stores
  • Create a NetworkClient contract that asserts parsing, 4xx/5xx handling, timeout and retry behavior across mock and real clients
  • Build a Cache contract testing TTL, eviction policy, persistence across init, and thread-safety for LRU and memory caches
  • Validate an Authentication contract that checks login success, rejection of bad credentials, token refresh, and logout state clearing

FAQ

Provide a factory closure (makeStore / makeClient) that constructs the concrete type and call or subclass the generic contract tests for that factory; each test then runs against the instance you supply.

Can contract tests cover asynchronous and error scenarios?

Yes. Generated suites use async tests and explicit error expectations so you can assert thrown errors, timeouts, and race-sensitive invariants.

What if an implementation intentionally diverges from the contract?

A failing contract test signals behavioral mismatch. If divergence is intentional, update the protocol/spec and regenerate the contract, documenting the change so all implementations can be updated.

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