Frontend/Backendアプリケーションのテストを書く場所はどこですか？

Question

単純なフロントエンド - バックエンド（REST API）アーキテクチャを使用してWebアプリケーションを作成したいと考えています。 テストをどこでどのように書くのかは私には分かりません。

フロントエンド：APIレスポンスを模擬してテストし、UX/UIのみをテストする必要がありますか？ バックエンド：ここでAPI呼び出しテストを作成し、最終的にはクラス単位でより詳細な単位テストを行う必要がありますか？

しかし、このように私はFrontendのテストが実際のAPIレスポンスを認識していないことを恐れています（バックエンドとは独立しているからです）。 私はAPIレスポンスを模倣せず、バックエンドからの実際の応答を使用しないと、Frontendクライアントは自分が望むデータを得るためにDBをどのように準備できますか？ - UX/UIテスト：

私がテストタイプの3種類を必要とするように私には思えるのフロントエンドは、モック応答 のセットで働いている - APIのテスト：APIは、セットの与えられた正しい答えを与えていますデータ - 統合テスト：フロントエンドは実際にバックエンドを（誰によって生成された）データセットで呼び出すかによって動作しています。

これを可能な限り無痛にするためのフレームワークまたはツールがありますか？ それはまあ

Answer 1

歓迎任意の提案

（私は多くのテストを書き換える必要がありますAPIの仕様が変更された場合）私には非常に複雑なようで、あなたは基本的に正しいです。このシナリオでは、バックエンドロジック、フロントエンドの動作、および統合の3種類のテストがあります。のは、それを分割してみましょう：あなたは、主にアプリケーションのビジネスロジックをテストしている

バックエンドをテストします。ただし、アプリケーションスタック全体（ドメイン、アプリケーション層、インフラストラクチャ、プレゼンテーション（API））をテストする必要があります。これらのレイヤーには、ユニットテストと統合テストの両方が必要で、ユーザーの視点からの純粋なブラックボックステストも必要です。しかし、これは複雑な問題です。完全な答えは非常に長くなるでしょう。アプリケーションのテストに関する一般的なテクニックに興味がある場合は、別のスレッドを開始してください。ここで

フロントエンドの振る舞い

フロントエンドアプリは正しい方法APIを使用する場合は、テストします。あなたはバックエンド層を模擬し、主に単体テストを書く。あなたが気づいたように、実際のAPI契約に関してはいくつかの問題があります。しかし、そのような問題を緩和する方法があります。まず、これらのソリューションのいずれかへのリンク：https://github.com/spring-cloud/spring-cloud-contract。今、いくつかの説明。アイデアは単純です：API契約は消費者によって推進されます。あなたの場合は、それはフロントエンドアプリになります。フロントエンドチームはバックエンドチームと協力して、クライアントのニーズをすべて満たす合理的なAPIを作成します。したがって、フロントエンドテストでは「実際のAPI」を使用することが保証されています。クライアントテストが変更されると、契約が変更されるため、バックエンドは新しい要件にリファクタリングする必要があります。

補足として、具体的なフレームワークを使用する必要はありません。チームにいくつかの規律を適用する場合、同じ方法論に従うことができます。消費者が最初に契約を定義することを覚えておいてください。

統合はあなたにも、いくつかの統合E2Eテストを必要とし、必ずすべての作品を作るために

をテストします。バックエンドアプリケーションの実際のテストインスタンスを設定します。次に、擬似モックアップ応答ではなく、実サーバを使用して統合テストを実行します。ただし、同じテストを他のレイヤーから複製する必要はありません。すべてが正しく統合されているかどうかをテストします。したがって、実際のロジックはテストしません。いくつかの障害シナリオを選択し、ユーザーの観点からこれらのテストを実行するだけです。したがって、バックエンドアプリの状態については何も想定せず、ユーザーのやりとりをシミュレートします。このようなもの：新製品の追加、製品の変更、更新された製品のフェッチ、または単一認証ポイントのチェック。そのようなテストは、ビジネスロジックを実際にテストするのではなく、実際のAPIテストサーバーがフロントエンドアプリと適切に通信する場合にのみ行われます。