testing

テスト

テストの作成とテスト戦略に関するチーム内の規約です。

テストの目的

テストに価値があるのは、動作が壊れたときに失敗する場合です。この基準ひとつで、何をテストすべきかをめぐる議論の大半は解決できます。テストで検出できるバグを具体的に挙げられないなら、それはカバレッジを装うだけのテストです。リファクタリングのたびに保守コストがかかるうえ、システムが壊れているのに成功を報告します。

以下のすべてに共通するのは、次の2点です。

• 出力をアサートします。戻り値、スローされたエラー、永続化された状態などです。 唯一のアサーションが expect(mock).toHaveBeenCalledWith(…) であるテストで検証できるのは、たった今書いた配線であって、動作ではありません。実装を正しく別の形に書き換えると失敗し、呼び出しだけを残して動作を壊すと成功します。どちらも逆です。
• 行ではなく、判断をテストします。 分岐、エラーの変換、状態遷移、境界条件などです。処理をそのまま委譲するだけのものや、条件分岐のないフィールドのマッピングには、間違える余地がありません。そのテストは、誰かがメソッド名を変更したときにしか壊れません。

カバレッジ率は最低限の目安であり、テストされていないファイルを見つけるものです。価値あるテストと形だけのテストを見分けることはできません。したがって、高い数値は「空の部分がない」と捉え、「テストの質が高い」とは考えないでください。

3つの観点

機能ごとに、次の3つすべてを確認してください。答えが同じテストから得られるとは限りません。

• 機能性 — 境界条件や失敗時も含め、正しく動作しますか？ UI がある場合は、操作可能性も含まれます。タブ移動で適切な場所にフォーカスが移ること、コントロールにアクセシブルな名前があること、自動 axe チェックに合格することを確認します。キーボードだけを使うユーザーが行き止まりに突き当たるのは、仕上げの問題ではなく機能上のバグです。
• パフォーマンス — 実際に想定される負荷とデータ量に耐えられますか？
• セキュリティ — エンドポイントごとに、具体的に次の点を確認します。認証情報がない場合は 401、認証情報は有効でもロールが違う場合は 403、別のテナントのオブジェクト ID が指定された場合は 404 または 403（オブジェクト自体は決して返さない）、形式不正またはサイズ超過の入力には 500 ではなく 400、リクエストの繰り返しには 429 を返すこと。また、レスポンスに nosniff、フレームポリシー、HSTS が含まれること。どれもそれぞれ1つのテストで確認でき、機能テストでは構造上見つけにくい種類のバグを検出できます。

規約

• テスト名は動作を表すものにします：should [outcome] when [condition]。CI で失敗したとき、名前だけで何が壊れたのかが分かるようにします。it('works') のような名前では、次の担当者が本体を読まなければなりません。
• テストは独立しており、実行順に依存しないものにします。 可変の共有状態があると、特定の順序でしか再現しない失敗が生じ、解決に何日もかかることがあります。
• 時間、乱数、環境を制御します。 実際の時計を参照するテストは、日付の境界や別のタイムゾーン、うるう秒のタイミングで失敗します。最悪のタイミングで発生し、常に本物のバグのように見えます。
• モックはプロセスの境界で使い、自分たちのユニット間では使いません。 内部のモックはそれぞれ新たに保守しなければならない第2の実装であり、実際の実装と乖離して、存在しなくなったシステムに対してテストが成功する状態になりかねません。
• モックは実際のレスポンスを漏れなく再現します。 本番では15個のフィールドを返すのに、スタブが { id, name } しか返さないと、テストには合格しても user.email でクラッシュします。現実に即したデフォルト値を持つファクトリーを使ってください。
• テストのためだけに、本番コードにメソッド（_resetForTesting）を追加してはいけません。 代わりにテストごとに新しいインスタンスを作成してください。本番コードにテスト用の関心事を含めると、それがユーザーにも届いてしまいます。
• 不安定なテストは失敗しているテストです。 隔離して先に進むと、赤を無視する習慣がチームに身につきます。そうなると、本物のリグレッションも見逃されてしまいます。
• 結果が返るまでの速さに応じて、テストスイートを段階分けします。 ユニットテストは保存時に実行し、5分以内を目安にします。統合テストはコミット時に実行し、15分以内にします。エンドツーエンドテストはプルリクエスト時に実行し、30分以内にします。それ以上かかるテストは夜間に実行します。重要なのは、開発者が結果を待つ時間です。内側のループが数分を超えると、ローカルで実行されなくなり、CI が失敗を最初に見つける場所になります。

見つかった問題の報告

テスト結果を報告する場合やカバレッジをレビューする場合は、軽微な項目や確信度の低い項目も含め、見つかった内容をすべて報告してください。重大度と確信度で順位を付け、対応するかどうかは別の工程で判断します。発見時に絞り込むと、実際の不具合を気づかれないまま見落とすことになり、読者には「何も見つからなかった」のか「見つけたが除外された」のか区別できません。

references/test-reports.md にレポートの形式と重大度の定義が記載されています。

参考資料

参考資料	読み込むタイミング
references/tdd-iron-laws.md	テストファーストで作業する場合。レッド・グリーン・リファクタリングの規律に従うとき
references/testing-anti-patterns.md	既存のテストをレビューする場合。何も検出できないテストを診断するとき
references/nestjs-jest-common.md	NestJS バックエンドの Jest テスト全般 — 下記の2つを読む前に確認
references/nestjs-jest-unit-tests.md	.spec.ts を作成するとき
references/nestjs-jest-contract-tests.md	稼働中の外部 API に対する .contract-spec.ts を作成するとき
references/test-reports.md	テストレポートまたは不具合報告を作成するとき