swift-testing-expert

Swift Testing

概要

このスキルは、最新の Swift Testing API を使って Swift のテストを作成、レビュー、移行、デバッグする際に使用します。読みやすいテスト、堅牢な並列実行、明確な診断を優先し、必要に応じて XCTest から段階的に移行してください。

エージェントの行動規範（次のルールに従ってください）

1. Swift のユニットテストと統合テストには Swift Testing を優先します。ただし、UI 自動化（XCUIApplication）、パフォーマンス指標（XCTMetric）、Objective-C のみのテストコードには XCTest を使用します。
2. #expect を既定のアサーションとして扱い、後続の行で前提条件となる値を使う場合は #require を使用します。
3. 並列実行に安全な方法を既定とします。テストが分離されていない場合は、.serialized を適用する前に、まず共有状態の修正を提案します。
4. 動作やメタデータには、命名規則やその場限りのコメントではなく、トレイト（.enabled、.disabled、.timeLimit、.bug、タグ）を優先します。
5. 複数のテストでロジックを共有し、入力値だけが異なる場合は、パラメーター化テストを推奨します。
6. OS ごとに動作を制限する場合は、テスト本体内の実行時 #available チェックではなく、テスト関数に @available を使用します。スイート型には @available を付けないでください。
7. 移行は段階的に進めるよう助言します。まずアサーションを変換し、次にスイートを整理してから、パラメーター化やトレイトを導入します。
8. Testing をインポートするのはテストターゲットのみとし、アプリ、ライブラリ、バイナリのターゲットではインポートしないでください。

最初の60秒（初期確認テンプレート）

• 目的を確認します。新しいテストの作成、移行、不安定な失敗、パフォーマンス、CI のフィルタリング、非同期の待機のいずれでしょうか。
• 必要最低限の情報を集めます。
  • Xcode／Swift のバージョンとプラットフォームのターゲット
  • 現在のテストで XCTest、Swift Testing、またはその両方を使用しているか
  • 失敗が決定的か、不安定か
  • テストが共有リソース（データベース、ファイル、ネットワーク、グローバル状態）にアクセスするか
• すばやく方針を分けます。
  • 繰り返しの多いテスト → パラメーター化テスト
  • ノイズの多い失敗や不安定な失敗 → 既知の問題への対処とテストの分離
  • 移行に関する質問 → XCTest との対応付けと併用方針
  • 非同期コールバックの複雑さ → continuation／await のパターン

参照先ガイド（適切なリファレンスをすばやく読む）

• テストの構成要素とスイートの整理 → references/fundamentals.md
• #expect、#require、スローの検証 → references/expectations.md
• トレイト、タグ、Xcode のテストプランによるフィルタリング → references/traits-and-tags.md
• パラメーター化テストの設計と組み合わせ → references/parameterized-testing.md
• 既定の並列実行、.serialized、分離の方針 → references/parallelization-and-isolation.md
• テストの高速化、決定性、不安定さの防止 → references/performance-and-best-practices.md
• 非同期の待機とコールバックのブリッジ → references/async-testing-and-waiting.md
• XCTest との併用と移行手順 → references/migration-from-xctest.md
• テストナビゲーター／レポートのワークフローと診断 → references/xcode-workflows.md
• インデックスとクイックナビゲーション → references/_index.md

よくある落とし穴 → 次に行うべきこと

• 繰り返しの多い testFooCaseA/testFooCaseB/... メソッド → 1つのパラメーター化された @Test(arguments:) に置き換えます。
• 後続のアサーションに隠れた、失敗する可能性のあるオプショナル値の前提条件 → try #require(...) を使ってから、アンラップした値をアサートします。
• 共有データベースを使う統合テストの不安定な失敗 → 依存関係を分離するか、インメモリーリポジトリを使用します。移行期間の措置としてのみ .serialized を使用します。
• 気付かないうちに古くなる無効化済みテスト → 一時的な既知の失敗には withKnownIssue を優先し、シグナルを維持します。
• 複雑な型で失敗値が分かりにくい → 型を CustomTestStringConvertible に準拠させ、焦点を絞ったテスト診断を実現します。
• テストプランの名前による対象の包含／除外 → タグとタグベースのフィルターを使用します。

検証チェックリスト

• 各テストが、必要に応じて、明確に動作を 1 つだけ検証し、内容を表す表示名を持っていることを確認します。
• 失敗した場合にテストを中止すべき前提条件には、#require が使われていることを確認します。
• 繰り返しのロジックが重複せず、パラメーター化されていることを確認します。
• テストが並列実行に安全であるか、意図的に直列化されており、その理由が示されていることを確認します。
• 非同期コードが await され、コールバック API が安全にブリッジされていることを確認します。
• 移行時に、サポート対象外の XCTest のみのシナリオは XCTest に残されていることを確認します。

参考資料

• references/_index.md
• references/fundamentals.md
• references/expectations.md
• references/traits-and-tags.md
• references/parameterized-testing.md
• references/parallelization-and-isolation.md
• references/performance-and-best-practices.md
• references/async-testing-and-waiting.md
• references/migration-from-xctest.md
• references/xcode-workflows.md