陌讯skills聚合平台

swift-testing-code-review

📁 existential-birds/beagle 📅 Jan 19, 2026

55

总安装量

54

周安装量

#3940

全站排名

安装命令

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

Agent 安装分布

gemini-cli 37

codex 37

claude-code 36

antigravity 32

github-copilot 30

Skill 文档

Swift Testing Code Review

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)
#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

Could pre-computed booleans in #expect lose diagnostic context?
Is #require stopping 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?

GitHub 仓库 ↗ ← 返回陌讯 Skills 聚合平台