existential-birds 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?