- name
- swift-testing-code-review
- description
- 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.
Swift Testing Code Review
Hard gates
Complete in order before recording Swift Testing review findings. Stack with beagle-ios: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
beagle-ios:review-verification-protocolbefore 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?