ユニットテスト：テスト戦略とフィクスチャ

ユニットテストの境界とフィクスチャの実践を定義し、コラボレーターの過剰モックや実装詳細を凍結されたAPIに変えることなく、ドメインの振る舞いに対して高速かつ決定論的な証拠を提供します。

パッケージステータス： 人間によるレビューのための参照コンテキストが準備完了。契約とテストシナリオは 完成していますが、採用実装がこれらを通過したという保証はありません。

決定事項

ユニットテストは、公開モジュールインターフェースを通じて決定論的なポリシーと状態遷移を検証します。明示的な関連値を持つ小さなビルダー、実際の値オブジェクト、制御されたクロックとランダム性、そして真のI/O境界でのみフェイクを使用します。

範囲

• テスト選択、ユニット境界、フィクスチャ、ビルダー、ダブル、時間/ランダム性、エラー、プロパティ、変更信頼性、命名、CIフィードバック。
• 依存関係をプロセス内で制御可能なドメインおよびアプリケーションコード。
• 統合テストおよび契約テストとの関係。

範囲外

• データベース、トランスポート、ブラウザ、またはプロバイダー統合テストの代替。
• 主な品質目標としての行カバレッジ追求。

契約

• 各テストは1つの観測可能な振る舞いに名前を付け、関連する状態のみを準備し、公開境界を呼び出し、安定した出力または状態をアサートする。
• フィクスチャは有効な最小オブジェクトをデフォルトとするが、振る舞いに重要なフィールドには明示的な値を要求する。
• クロック、ID、ランダム性は注入またはキャプチャされ、失敗が再現可能である。
• モックは相互作用自体が契約である場合にのみプロトコルを検証し、それ以外はフェイクまたは出力アサーションを優先する。
• エラーテストはドメインコードと安全なコンテキストをアサートし、文言が公開APIでない限り脆弱な全文メッセージは避ける。
• バグ修正は欠陥を防止できるレイヤーで最小の失敗テストを追加する。

実装ガイダンス

• 名前付きシナリオプリセットを持ち、隠れたネットワーク/データベース呼び出しのない型付きフィクスチャビルダーを作成する。
• 境界分割にはテーブルテストを、代数的不変条件にはプロパティテストを適宜使用する。
• アサーションのないカバレッジを発見するために、定期的にミューテーションテストやターゲット障害注入を実行する。
• 共有フィクスチャは1つのドメインに限定し、公開契約フィクスチャは意図的にバージョン管理する。

失敗処理と安全策

• フレークするユニットテストは所有者と期限付きで隔離されるのみで、その保護された振る舞いは代替証拠が必要。
• テストが内部の過剰なモックを必要とする場合は、モジュール境界を再検討するか振る舞いを統合テストに移す。
• グローバルクロックやランダムシードがテスト間で漏れる場合は、実行順序に依存せず分離する。

検証と運用

• 実行時間分布、フレーク率、リトライで隠れた失敗、変更コードのテストカバレッジ、重要モジュールのミューテーションスコア、欠落テストレイヤーによる逸脱欠陥を追跡する。
• 高速なプリサブミット層と明示的な予算を持つ完全なユニット層を維持する。
• フィクスチャの増加や重複セットアップを設計のシグナルとしてレビューする。

このパッケージ内の実行可能に見える例はフィクスチャおよび受け入れ契約です。
コレクションのルートから python tools/validate.py を実行してパッケージ構造とメタデータをチェックし、対象リポジトリでシナリオを実装・実行してください。

採用前提

• example.yaml の名前と数値は採用プロファイルであり、普遍的なデフォルトではありません。
• 採用チームはアクター、データクラス、エラー語彙、所有権を自システムにマッピングする必要があります。

参考文献

• 外部の規範的なソースは不要であり、このパッケージはプロジェクトの決定を定義します。