mcpField
S
swift-testing-code-review

swift-testing-code-review

github.com/existential-birdsTesting & quality85191 installsUpdated 11w ago
Repository

About swift-testing-code-review

A review skill for Swift Testing code, aimed at reviewers who need an ordered scope and evidence check before reporting issues. It provides a checklist and points to focused references for common testing patterns.

Key features

  1. 01Ordered scope and code-surface checks
  2. 02Evidence requirements for review findings
  3. 03Checklist for assertions and test organization
  4. 04References for async and parameterized tests

Use cases

  1. 01Reviewing Swift Testing assertions
  2. 02Checking parameterized test behavior
  3. 03Assessing async test patterns

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/existential-birds/beagle --skill swift-testing-code-review

After installing, type/swift-testing-code-reviewin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
async-testing.md
expect-macro.md
organization.md
parameterized.md

Details

From the project README

Swift Testing Code Review

Hard gates

Complete in order before recording Swift Testing review findings. Stack with review-verification-protocol for universal review rules.

  1. Scope: You have an explicit list of .swift paths under review (or a user-named single file). Pass: Paths captured in working notes or one line: No Swift files in scope — then stop with no findings.
  2. Swift Testing surface: For each path you treat as Swift Testing code, confirm import Testing or @Test / #expect / #require / @Suite appears in that file (open or search). Pass: At least one match per critiqued file, or you exclude that file from Swift Testing review with a one-line reason (e.g. XCTest-only).
  3. Evidence + protocol: Load review-verification-protocol before asserting any issue. Pass: Each finding meets that skill’s anchor rules; any violated Review Checklist item cites [FILE:LINE] evidence. If you report zero issues, state Protocol applied; no Swift Testing issues (or equivalent) in the review summary.

Quick Reference

Issue TypeReference
#expect vs #require, expression capture, error testingreferences/expect-macro.md
@Test with arguments, traits, zip() pitfallsreferences/parameterized.md
confirmation, async sequences, completion handlersreferences/async-testing.md
@Suite, tags, parallel execution, .serializedreferences/organization.md

Review Checklist

  • Expressions embedded directly in #expect (not pre-computed booleans)
  • #require used only for preconditions, #expect for assertions
  • Error tests check specific types (not generic (any Error).self)
  • Parameterized tests with pairs use zip() (not Cartesian product)
  • No logic mirroring implementation in parameterized expected values
  • Async sequences tested with confirmation(expectedCount:)
  • Completion handlers use withCheckedContinuation, not confirmation
  • .serialized applied only where necessary (shared resources)
  • Sibling serialized suites nested under parent if mutually exclusive
  • No assumption of state persistence between @Test functions
  • Disabled tests have explanations and bug links

When to Load References

  • Reviewing #expect or #require usage -> expect-macro.md
  • Reviewing @Test with arguments or traits -> parameterized.md
  • Reviewing confirmation or async testing -> async-testing.md
  • Reviewing @Suite or test organization -> organization.md

Review Questions

  1. Could pre-computed booleans in #expect lose diagnostic context?
  2. Is #require stopping tests prematurely instead of revealing all failures?
  3. Are multi-argument parameterized tests creating accidental Cartesian products?
  4. Could zip() silently drop test cases due to unequal array lengths?
  5. Are completion handlers incorrectly tested with confirmation?

Comments

Markdown supported