writing-tests

テストの作成

ルールは実証できるシグナルがなければ、テストも作らないことです。差分をなぞったり、リテラルを維持したり、小さな変更を安全に見せたりするためにテストを追加しないでください。編集とは独立して回帰する可能性のある動作を証明できるときに、そのテストには価値があります。

テストの対象は、ビジネス動作、不変条件、変換、実行時および権限の境界、生成の契約、ユーザーに見えるワークフローです。意味のある失敗が「この静的な値が変わった」だけのテストは、通常、保護ではなく重複です。

このテストを書く価値はありますか？

テストに価値があるのは、次のすべてを満たす場合に限られます。1つでも満たさない場合は、書き直すか、作成しないでください。

1. 実装ではなく、動作を検証する。 戻り値、スローされるエラー、永続化された状態の変化、描画またはエクスポートされた出力、API／CLI のレスポンス、生成された成果物、外部から確認できる副作用など、観測可能な契約を検証します。無害な内部リファクタリングでテストが失敗してはいけません。
2. 変更に反応する。 動作が微妙に誤っている場合に失敗するアサーションが少なくとも1つあります。たとえば、条件が反転する、境界が変わる、定数が返される、永続化された状態が欠落する場合です。
3. 自明ではない。 設定した値を返すゲッター、入力をそのまま返すパススルーヘルパー、ラップ対象の関数を呼び出すだけのラッパー、それ自身のリテラルを手作業でコピーした列挙型配列、公的エクスポートのアサーション、型システムの実行時アサーションではありません。
4. 独立している。 単独でも、どの順序でも合格します。共有された可変状態、隠れた時計への依存、フィクスチャの順序への依存がありません。
5. 適切なレイヤーで検証する。 純粋な計算／パーサー／リデューサー／セレクターのロジックは、高速な単体テストに適しています。データベース、スキーマ、バリデーター、権限、実行時の動作、複数ユニットの配線は、プロジェクトの実際のハーネスを使った統合テストに適しています。ユーザーの一連の操作全体は、エンドツーエンド検証に適しています。
6. 重複していない。 同じ動作が、より低コストのレイヤーですでにカバーされていません。

バグ修正では、元の失敗を起点にしてください。通常、最も価値の高い検証は、失敗したルート、API、ブラウザーフロー、コマンド、または統合の接点です。修正中に作られたヘルパーの単体テストは、そのヘルパー自体が失敗した動作を担っていない限り、回帰テストにはなりません。

追加してはいけないテスト

• 実装データや、変更された単一のリテラルをなぞるテスト。静的な設定行、カタログのステータス、ナビゲーションのメンバー、ルートテーブル、フィーチャーフラグのデフォルト値、ラベル、文言、ステータス一覧などです。
• ライブラリ側ですでに検証されているライブラリの動作を対象にするテスト。
• コードを抽出したことだけを理由に作成するテスト。
• ゲッター／セッター、パススルー、1行のラッパー、公的エクスポート、型だけを対象にするテスト。
• モックが、テストで指示したとおりに呼び出されたことを検証するテスト。
• 抽出したロジックとブラウザー／E2E 検証で、より直接的に動作を証明できる場合の React／コンポーネントのマウントテスト。
• 主張する種類のバグを検出できない、見せかけの統合テスト。たとえば、実際のスキーマ、バリデーター、インデックス、トリガー、権限、実行時の動作に依存する処理を、手作りのデータベースエミュレーターでテストする場合です。
• 理由を考えずに再生成するスナップショットやゴールデンテスト。

適切なテストの形

• ビジネス計算、状態遷移、検証、フィルタリング、導出、権限、パーサーの動作、データ変換、生成の契約、複数ファイル間の整合性、冪等性、クラス全体の不変条件。
• 往復性、保存性、可換性、正規化、単調性、「境界で1回だけ丸める」といった広範な不変条件に対するプロパティテスト。「例外が発生しない」というプロパティより、不変条件を優先してください。
• 実際のスキーマ、バリデーター、インデックス、トリガー、権限、プロバイダー／実行時の境界、複数ユニットの配線に依存する動作の統合テスト。
• 成果物そのものが契約である場合に限ったゴールデンテスト。たとえば、出力されたイベントの形状、公開プロトコルの出力、描画されたドキュメントのテキスト／構造、マイグレーションの動作、生成コード、プロバイダーのレスポンス解析です。更新コマンドを明示し、意図した場合に限って再生成してください。

構成とランナー

プロジェクトで確立されているテストアーキテクチャに従います。ランナー、ディレクトリ構成、フィクスチャの慣例、ファイル名のサフィックス、パッケージスクリプト、テスト階層を確認してください。独自のパターンを新たに作らないでください。

プロジェクトにデフォルトのランナーがある場合は、それを使用してください。別のランナーを使用するのは、必要なランタイム、DOM 環境、ネイティブのビジュアルテスト用ハーネス、モジュールのリセット機能、フレームワークコンパイラー、統合テストライブラリなど、実際に避けられない制約がある場合に限ります。プロジェクトに明示的なルールがない限り、同じパッケージや領域で複数のランナーを混在させないでください。

プロジェクトに共有フィクスチャの慣例がない限り、フィクスチャとビルダーはテストの隣に配置してください。プロバイダーや API のフィクスチャは、実際のレスポンスの意味を保ってください。必要であればサイズを小さくしてもかまいませんが、意味は変えないでください。

AI による作成のガイダンス

まずアサーションを書き、その後にセットアップを行ってください。テストごとに、意味のあるアサーションを 1〜3 個にすることを推奨します。エージェントが見落としがちな失敗ケース、すなわち null、空の値、境界値、エラー、並行処理、権限、ビジネスルールの境界条件を対象にしてください。

対象のテストと、変更した領域に必要なプロジェクトのチェックを実行してください。バグ修正では、実用上可能であれば、元の不具合がある状態でテストが失敗することを確認してください。