Webテスト戦略

テスト戦略：信頼性の高いテストスイートの構築

優れたテスト戦略は、バグを早期に発見し、自信を持ってリファクタリングし、より迅速に出荷するのに役立ちます。しかし、すべてのテストが同じように作られているわけではなく、すべてをテストすることが適切なアプローチであることはほとんどありません。鍵は、最も価値を提供する場所にテストの労力を集中することです。

何をテストするか

ビジネスロジック、つまりコードの中で意思決定を行いデータを処理する部分のテストに焦点を当ててください。配送料を計算したり、ユーザー入力を検証したり、ビジネスルールを適用したりする関数は、テストの良い候補です。データベースからUIにデータを渡すだけの関数は、独自のテストを必要としないかもしれません。

エッジケースをテストしてください：入力が空、null、または不正な形式の場合はどうなりますか？データベースが利用できない場合はどうなりますか？ユーザーに権限がない場合はどうなりますか？これらのエッジケースにバグが潜んでいます。

テストトロフィー

従来のテストピラミッド（多数の単体テスト、少数の統合テスト、少数のE2Eテスト）は、テストトロフィーモデルによって洗練されてきました。このアプローチは、ユーザーがアプリケーションを使用する方法でアプリケーションをテストするが、完全なブラウザテストの不安定さがない統合テストを重視します。

実際のデータベースを使用してAPIエンドポイントをテストする統合テスト、または実際のレンダリング環境を使用してReactコンポーネントをテストする統合テストは、テストごとに最大の信頼性を提供します。これらは、最も重要な種類のバグ（ものが適切に連携して動作しないこと）をキャッチし、すべてのコミットで実行できるほど高速で信頼性があります。

テスト可能なコードの作成

テストしやすいコードは、通常、より適切に設計されています。1つのことを行い、明確な入力と出力を持つ関数はテストしやすいです。グローバル状態に依存したり、ネットワーク呼び出しを行ったり、副作用がある関数はテストが難しくなります。依存性注入（関数内で依存関係を作成するのではなく、パラメータとして渡すこと）により、コードのテストが容易になります。

純粋関数（同じ入力に対して常に同じ出力を返し、副作用がない関数）は、最もテストが簡単です。セットアップ、モック、クリーンアップは一切必要ありません。ビジネスロジックが純粋関数にあり、I/Oを処理するインフラストラクチャコードから分離されるようにコードを構造化するようにしてください。

テストの効果的な実行

優れたテストスイートは高速に実行されます。テストに時間がかかりすぎると、開発者はテストを実行しません。統合テストにはインメモリデータベースを使用してください。外部サービスをモックしてください。ファイルを保存するたびに単体テストを実行してください。CIで完全なテストスイートを実行してください。そして、テストの失敗が明確であることを確認してください。失敗したテストは、何がどこで間違っていたかを正確に示す必要があります。

テストカバレッジは有用な指標ですが、目標ではありません。100%のカバレッジは、アプリケーションにバグがないことを意味するわけではありません。重要なパスとエッジケースのテストに焦点を当ててください。意味のあるアサーションなしにコードを実行するだけの多くのテストよりも、適切に記述された少数のテストの方が価値があります。