さまざまなタイプのテストに付けられた名前は、コードベース全体で共通のテーマを持つ傾向にありますが、特に厳密な定義はありません。このコースでは、各タイプのテストの意味に関するガイドラインを示しますが、他のリソースで定義が異なる場合があります。
これまでのページでは、単体テストとコンポーネント テスト（この例では React コンポーネントを参照）の例を示しました。どちらもテストのピラミッド（または他の形状）に配置できます。これらは複雑性が低く、実行が高速ですが、より複雑な統合テストほど有用ではない場合があります。
一般的なテストの種類
単体テスト
単体テストは最も小さなスコープです。これらは、コードの小さな部分、つまり純粋にステートレスなコードを、ほぼ数学的な方法でテストするために使われる傾向があります。入力 X、Y、Z をコードに提供した場合、出力は A、B、C になります。
通常、単体テストを含むコードには、ネットワークからの取得や他の関数やライブラリの暗黙的な使用など、外部依存関係はありません。コードを「切り取って」テストできるツリーノードです。
単体テストは、たいていは簡単に作成して実行できますが、コードを小さくテストしても有用な情報が得られないことは常にあります。多くの場合、コード ユニットに他のコードとの相互作用がないと、リスクを軽減するために、より高いレベルでテストを行うほうが適切です。
コンポーネント テスト
ウェブ デベロッパーにとって「コンポーネント」はオーバーロードとなり、React コンポーネントやウェブ コンポーネントなどのユーザーに表示されるコンポーネントを意味します。より一般的な定義は、テスト可能な作業チャンク（外部依存関係を持つクラスなど）です。このコンポーネントを効果的にテストするには、このコンポーネントの依存関係をモックアウトまたはスキップする必要があります。
最新のウェブ開発手法はコンポーネントのコンセプトに基づいているため、コンポーネントのテストは、テストについて実用的な方法です。たとえば、各コンポーネントにテストが必要だと判断できます。単一のデベロッパーまたは小規模なチームがコンポーネントの所有権を明白に主張している場合、コンポーネントのテストはフォローアップも簡単です。ただし、複雑な依存関係をモックアップするのは難しい場合があります。
統合テスト
これらは、コンポーネント、モジュール、サブシステム、コードの他の意味のある部分を小さなグループにまとめてテストし、正しく機能することを確認する傾向があります。これは非常にあいまいな定義ですウェブ デベロッパーにとって、テスト対象のコードは、サイトの実際の（またはそれに近い）本番環境ビルドではないものの、システムのさまざまな関連コンポーネントを接続するものだと考えてください。
これには、純粋なモックではなく、テストモードの外部データベースなど、「実際の」依存関係が含まれることもあります。たとえば、統合テストでは、query() が常に同じ 2 つのエントリを返すのではなく、テスト データベースに何かがあることを確認できます。データ自体はそれほど重要ではありませんが、ここではデータベースに接続して正常にクエリを実行できるかどうかをテストします。
さまざまなコンポーネントに接続された単一のアクションが一連の測定可能な影響を引き起こす可能性があるため、アサーションを使用してチェックできる、広範な意味を持つ比較的シンプルな統合テストを作成できます。このため、統合テストでは、複雑なシステムが意図したとおりに動作することを効果的に実証できます。ただし、記述と保守が困難になるだけでなく、不必要に複雑になる可能性もあります。たとえば、統合テスト用に FakeUserService を作成すると、それと RealUserService の両方で UserService を実装するという要件が追加されます。
スモークテスト
これらのテストは迅速に完了し、コードベースが適切な状態かどうかを判断する必要があります。実際には、これは主に、エクスペリエンスに幅広い影響を与えるコードに対して簡単なテストを実施することを意味します。
たとえば、大規模なログイン ウェブアプリの場合、ログインと認証システムが機能するようにします。これがないとアプリは使用できず、さらにテストを行う意味がないためです。
スモークテストは、大規模なコードベースの package.json の test スクリプトで実行することをおすすめします。手動テストは一種のスモークテストとしても機能します。
回帰テスト
回帰テストはスモークテストの一種で、新しいリリースやその他の機能開発の後に既存の機能が引き続き動作すること、または古いバグが再導入されないようにすることを保証します。
これは、テストドリブン開発（TDD）のコンセプトに関連しています。バグを明示的にトリガーするために記述され、後でバグが修正されたことを確認するために作成されたテストケースは、回帰テストケースとしてカウントされます。これは、同じバグが戻らないようにするためです。
しかし、回帰テストは、優れたソリューションがなければ問題になる可能性があります。ビジネスニーズでよく取り上げられる用語です。機能を開発する際には、古い機能が壊れないようにすることが重要になります。十分にテストされたコードベースでこれを維持できるはずですが、実際のコードベースは必ずしもその理想に応えるとは限りません。これについては、以降のセクションで詳しく説明します。
ビジュアル テスト
ビジュアル テストでは、ウェブサイトの状態のスクリーンショットまたは動画を撮影して、現在のテスト実行と照らし合わせて既知の良好な状態（前のスクリーンショットなど）を確認します。本質的に、HTML、CSS、ウェブサイトの他の部分をレンダリングするには、実際のブラウザを実行する必要があります。
コードベース全体を実行するエンドツーエンド テストを視覚的にテストするのではなく、特にさまざまな画面サイズで特定のコンポーネントのみをレンダリングしてレスポンシブ UI をトリガーする HTML の「ハーネス」を作成すると便利です。これは、JSDOM や同様のフレームワークだけを使用する場合よりも複雑です。
目視テストの失敗は、他の種類の破損を示す良い兆候かもしれません。ただし、複雑な UI は、テストしようとしている機能とは無関係な理由で、ビジュアル テストが失敗することがあります。たとえば、他の新機能によって UI の外観が変更された場合や、新しい OS バージョンによる絵文字のレンダリングが以前のバージョンと異なる場合などです。
エンドツーエンド テスト
多くの場合、エンドツーエンド テストはテストピラミッドの頂点にあります。ウェブアプリやウェブサイトの操作全体を表します（特定の機能を中心とする）。通常、WebdriverIO、Selenium、Puppeteer などのエージェントによって制御されるブラウザ内で実行されます。このブラウザは、本番環境にデプロイする場合とほぼ同じでコードベースを実行できます（ローカルホストで提供されます）。
サイトによっては、テストユーザーとしてログインし、重要な操作を行うか、サイトまたはシステムが正しい状態にあるかの確認などを行います。この種のテストは非常に強力ですが、メンテナンスが難しい場合があるため、以降のセクションで別の例を紹介します。
これらを簡素化するための戦術としては、スコープを縮小することや、必要に応じて特定のコンポーネントをモックアウトすることなどがあります。たとえば、ユーザーがサイトにログインする必要があるが、ログインがテスト対象の機能ではない場合、テスト環境用のフラグを設定して、ログインや関連する Cookie の作成を行わずにテスト コントローラがユーザーとして機能するようにすることをおすすめします。
エンドツーエンド テストは、コードベースの大規模なテストを一度に行うには非常に効果的な方法ですが、このような大規模なテストは、外部システムに依存しているため、不安定になったり信頼性が低くなるリスクがあります。また、すべてのテストでエントリが作成または変更された場合など、データベースに大量のテストデータが残ることがよくあります。このような残ったデータを蓄積すると、テストがどのように失敗したかを判断するのが難しくなる可能性があります。
API テスト
API テストとは、ソフトウェアが提供する API の動作を確認すること、または実際の（ライブの）API にアクセスして動作を確認することです。いずれにせよ、この手法では、統合テストのように実際に統合することなく、システム間の抽象化（最終的な相互通信）をテストする傾向があります。
これらのテストは、接続をテストするシステムを実行するオーバーヘッドなしに、統合テストの基本的な前身として使用できます。ただし、実際のシステムのテストは不安定になることがあります。
その他のタイプ
ソースに応じて、他にもさまざまなテスト方法が有用です。以下は興味深い例です。
- 手動テスト。
- 承認テストは Agile によって普及した手動テストの一種であり、製品が「ユーザーのニーズを満たしている」ことを確認します。
- カオステストとは、ランダムなデータを入力して何が起こるかを確認し、不正なデータが入力されてもサイトがクラッシュしないようにすることです。
- 障害テストでは、ネットワーク障害などの複雑なシステムの障害を意図的にシミュレートして、テスト対象のコードが制御された方法で応答していることを確認します。
- ビルドテストでは、コードベースのビルド アーティファクトが存在すること、またはその内容を確認することで、生成できることを確認します。このテストタイプは、複雑な CMS の出力を確認する場合に便利です。
コード カバレッジ
自動テストでテストされたコードの割合を測定し、それを統計として時系列でレポートできます。コード カバレッジを 100% にすることはおすすめしません。100% のコード カバレッジを使用すると、不要なオーバーヘッドが発生し、テストが単純化または不適切になり、主要なユースケースを詳細にカバーできない可能性があります。
カバレッジ自体は、テスト（特に統合テスト）の作成や作業を行う際にも便利なツールです。1 回のテストでテストされるコードのパーセンテージまたは行ごとの内訳を表示することで、不足しているコードや次にテストできるコードを把握できます。
リソース
理解度をチェックする
既知のテストのタイプは次のうちどれですか。