superior-testing

優れたテスト

動作とリスクについて、長期にわたって信頼できる根拠を示すテストを作成します。テストスイートはリポジトリの既存のツールやアーキテクチャに合わせ、汎用的なテストピラミッド、フレームワーク、カバレッジ目標を押し付けないでください。

契約を明確にする

テストを書く前に、次の点を特定します。

• 保護する対象となる、観測可能な動作または不変条件。
• テストで判別すべき障害またはリグレッション。
• その動作を観測できる公開境界。
• 関連する依存関係、状態、時間、並行処理、外部システム。
• 既存のテスト規約、ヘルパー、フィクスチャ、CI の制約。

報告されたバグについては、実用上可能であれば実装を変更する前に障害を再現します。フィクスチャ、環境、アサーションの不備ではなく、意図した理由でテストが失敗することを確認してください。

信頼できる範囲で最も狭いテストを選ぶ

単体テスト、コンポーネントテスト、統合テスト、コントラクトテスト、エンドツーエンドテスト、プロパティベーステスト、移行テストのいずれを選ぶか検討する場合、または変更が複数の層でのカバレッジを必要とする場合は、references/test-strategy-and-levels.md を読んでください。

リスクを実際に担う箇所を検証する、最も低コストのテストを優先します。

• 安定した呼び出し可能な境界での純粋なルール。
• 永続化、シリアライズ、フレームワークの接続、サービス境界を対象とした統合テスト。
• 独立して変更されるプロデューサーとコンシューマーを対象としたコントラクトテスト。
• 配線自体がリスクとなる、少数の重要な利用経路を対象としたエンドツーエンドテスト。

同じアサーションをすべての層で繰り返さないでください。別の層を追加するのは、それによって異なる障害モードを証明できる場合に限ります。

テストの有効性を高める

• プライベートなメソッド呼び出しではなく、観測可能な結果、状態遷移、発生した効果、または安定したコントラクトをアサートします。
• 根拠のない組み合わせではなく、コントラクトに基づく代表的な境界ケースと無効な入力を使用します。
• 各失敗の診断情報を十分に保ち、どのコントラクトが破られたのかを特定できるようにします。
• スナップショットは小さく、意図的なものにします。広範囲にわたるスナップショットの変更をそのまま受け入れず、意味上の変更を確認してください。
• 行カバレッジは調査の手がかりとして扱い、正しさの証明とはみなさないでください。
• テストが目的を表現する妨げにならない限り、既存の命名規則と構造を維持します。

依頼された範囲で許容され、実際の設計を改善する場合は、テストしやすくするための小さな接点を本番コードに設けてもかまいません。テストハーネスを満たすことだけを目的に、プライベートな内部実装を公開したり、依存性注入の仕組みを追加したり、動作を変更したりしないでください。

実行の信頼性を保つ

テストで共有フィクスチャ、データベース、ファイル、ネットワーク、時間、乱数、非同期処理、並行処理、再試行、断続的な失敗を扱う場合は、references/reliable-test-design.md を読んでください。

• 管理下にある境界で時間と乱数を制御します。
• 推測した時間だけスリープするのではなく、観測可能な条件を待ちます。
• 変更可能な状態を分離し、失敗した場合もクリーンアップします。
• テスト対象の内部コラボレーションではなく、外部との所有境界をモックします。
• 断続的に失敗するテストについて、未解決の原因を特定して記録しないまま、再試行、タイムアウトの延長、実行のスキップで隠さないでください。

変更に応じて実行する

まず影響を受ける最小範囲のテストを実行し、その後、リポジトリの慣例と変更のリスクに応じて、関連するテストスイート、型チェック、リンター、ビルドチェックを実行します。明示的な許可と承認済みの環境がない限り、破壊的な統合テスト、本番トラフィックを使った実験、共有外部システムを変更するテストは実行しないでください。

次の内容を報告します。

• 対象とした動作とリスク。
• テストのレベルと、それが信頼できる理由。
• 実行したコマンドと確認できた結果。
• 変更前から発生していた失敗、または未解決の失敗。
• 検証していない重要な環境や条件。

スキルを適切に組み合わせる

• より広範な変更セットレビューの中で、テストがリスク領域の一つとなる場合は、superior-code-reviewを使用します。
• テストの失敗が、テスト設計の問題ではなく、本番環境または環境における未知の原因を示す証拠である場合は、superior-debuggingを使用します。
• テスト対象の動作が、マイグレーション、実際のエンジンとの統合、トランザクション、またはデータ互換性の契約に関わる場合は、superior-databaseを使用します。
• ベンチマークの方法論、パフォーマンス予算、容量チェック、または回帰しきい値が主な対象となる場合は、superior-performanceを使用します。
• 制御された障害、縮退、復旧、フェイルオーバー、または復元のテストが主な対象となる場合は、superior-reliabilityを使用します。
• テスト環境またはゲートをパイプラインとリリース検証が担う場合は、superior-deliveryを使用します。
• テストが、ビジネスルール、状態遷移、永続化、またはAPI動作の変更に伴う場合は、superior-logicを使用します。
• 脅威に基づくネガティブケースやセキュリティ制御の検証には、superior-api-securityを使用します。
• 主張する動作がインターフェース上の懸念事項に属する場合は、superior-accessibility、superior-responsive、またはsuperior-uiを使用します。
• テスト戦略、検証手順、または実装内容によって、プロジェクトの永続的な知識が更新される場合に限り、superior-docsを使用します。

焦点を絞ったテストの依頼を、無関係な本番コードのリファクタリングや、テストスイート全体の書き換えにまで広げないでください。