Swift testing code review
Skill existential-birds/beagle/plugins/beagle-ios/skills/swift-testing-code-review
Agent Skills marketplace: framework-aware skills for code review, documentation, test-plan generation, AI-writing detection, architectural analysis, and git workflows — for Python, Go, Rust, Elixir, React, Remix, and iOS/Swift. Works with Claude Code, Codex, and any agent that supports Agent Skills.
npx -y skills add existential-birds/beagle --skill swift-testing-code-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Reviews Swift Testing code for proper use of #expect/#require, parameterized tests, async testing, and organization. Use when reviewing .swift files with import Testing, @Test, #expect, @Suite, or confirmation patterns.
SKILL.md
3.3 KB, as published. Nobody here has run it
Swift Testing Code Review
Hard gates
Complete in order before recording Swift Testing review findings. Stack with review-verification-protocol for universal review rules.
- Scope: You have an explicit list of
.swiftpaths 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. - Swift Testing surface: For each path you treat as Swift Testing code, confirm
import Testingor@Test/#expect/#require/@Suiteappears 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). - 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, stateProtocol applied; no Swift Testing issues(or equivalent) in the review summary.
Quick Reference
| Issue Type | Reference |
|---|---|
| #expect vs #require, expression capture, error testing | references/expect-macro.md |
| @Test with arguments, traits, zip() pitfalls | references/parameterized.md |
| confirmation, async sequences, completion handlers | references/async-testing.md |
| @Suite, tags, parallel execution, .serialized | references/organization.md |
Review Checklist
- Expressions embedded directly in
#expect(not pre-computed booleans) -
#requireused only for preconditions,#expectfor 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, notconfirmation -
.serializedapplied only where necessary (shared resources) - Sibling serialized suites nested under parent if mutually exclusive
- No assumption of state persistence between
@Testfunctions - 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
- Could pre-computed booleans in
#expectlose diagnostic context? - Is
#requirestopping tests prematurely instead of revealing all failures? - Are multi-argument parameterized tests creating accidental Cartesian products?
- Could
zip()silently drop test cases due to unequal array lengths? - Are completion handlers incorrectly tested with
confirmation?