統合テスト (例付き)

以前に、ユーザー インターフェイス (UI) のテストは (時間の点で) コストがかかるため、より多くのシステム統合テストを作成する可能性について簡単に説明しました。したがって、この記事ではシステム統合テストを紹介します。

UI テストは、ボタンのクリック、ページのスクロール、表示されたデータが正確であることを確認するためのデータの確認など、手動でテストしていた手順を自動化できるため、常に楽しく記述できます。自動テストの実行をスケジュールし、レポートが生成されるのを待ち、テスト シナリオが失敗したかどうかを確認するだけです。

アプリケーションの機能が増えると、より多くの UI テストが作成されます。UI テストのセットを完了するには、不安定なテスト、テスト シナリオの高度なメンテナンス、およびより長い実行時間が必要です。悪夢が起こったとき、私たちは別の角度から問題を解決しようとします。私たちは何をすべきで、何をすべきではなかったのでしょうか? テスト データのさまざまな順列 (たとえば、さまざまなデータ セットを取得するさまざまな種類のログイン) を処理する UI テスト — これらすべてを代わりにシステム統合テストで実行できますか?

統合テストは、さまざまなモジュールが必要な機能に従って適切に連携できることを確認するために実行されます。これは、API または UI テストの統合、あるいはその両方である可能性があります。

統合テストの作成を開始するには、アプリケーション フローをよく理解する必要があります。では、オンライン ライブラリから本を借りる場合の次の例を見てみましょう。API の統合と UI テストの両方の観点から検討することに注意してください。

UI テスト シナリオ: ログインが成功したときにユーザー アカウントの詳細を確認する

API の統合は次のようになります。

UI テスト シナリオ: ログインが成功したときに、ユーザーの本の貸与の詳細を確認する

API の統合は次のようになります。

次に、API の統合テストをさらに作成し、UI テストを減らす方法を見ていきます。オンライン図書館システムには次の要件があると仮定します。

• 2 種類のメンバーシップ: {ベーシック、プレミアム}
• 一部の書籍はプレミアム タイプのみで利用可能

UI テスト シナリオ: ログイン成功時に書籍を表示する

さまざまなメンバーシップ タイプに対して (UI テストで) テスト シナリオを複製する代わりに、データ駆動型 BDD を利用できます。また、ほとんどの人は、UI テストでさまざまなシナリオをカバーしたからといって、統合テストでは 1 つのシナリオだけをカバーする必要があるという考え方を持っています。

API の統合は次のようになります。

このアプローチを使用する際の問題は、将来、より多くの種類のメンバーシップが導入される場合、UI テストの実行を完了するのに時間がかかることです。これは、UI テストでは、アクションがトリガーされる前に最初に DOM 要素を検出する必要があるためです。

例:
ユーザーが [送信] ボタンをクリックする前に Web ページを下にスクロールする必要がある場合、ページを下にスクロールする手順を定義する必要があります。UI テストの数を減らして代わりに統合テストの数を増やす場合は、データがいずれかのメンバーシップ タイプで正しく表示されるかどうかを確認するために 1 つの UI テストを記述するだけで済みます。

UI テスト シナリオ: ログイン成功時に書籍を表示する

統合テストに関しては、2 セットのテスト (メンバーシップ タイプごとに 1 つのテスト) を使用できます。各テストでは、フェッチされた書籍の詳細が各メンバーシップ タイプに対して正しいかどうかを検証します。

API の統合は次のようになります。

より多くの統合テストを行うことで、データに関連するバグを解決する際の時間を節約できます。ただし、フォームのキャプチャなど、手動でテストを行う必要がある場合があることに注意してください。一部のシナリオは、自動化が技術的に実現不可能であるか、自動化するのに多大な労力がかかります。

統合テストがどのように機能するか、および統合テストが UI テストの数を減らすのにどのように役立つかについての理解を深めていただければ幸いです。プロジェクト チームが異なればテスト戦略も異なる場合があります。プロジェクトに最適な戦略を見つけられることを願っています。

労働者の日おめでとう！皆さん、安全で健康に（家で）過ごしてください〜❤️❤️❤️

- マーリン