私の職場では、最近、作成したいくつかの RESTful API をテストするために、いくつかのテスト スイートをまとめました。サービスと同様に、私たちのサービスも依存する他の RESTful API を呼び出すことができます。2つのスイートに分けました。
私は間違いなくこれを行うことをお勧めします。それは私たちにとって本当にうまくいきました。主な利点は次のとおりです。
- ピア サービスはモック化されているため、複雑なデータ セットアップを実行する必要はありません。各テストの前に、Mockito を使用した単体テストのクラスと同じように、restito を使用してピア サービスの動作を定義するだけです。
- このスイートは、モック化されたサービスが事前に用意されたメモリ内応答を提供するため、非常に高速です。そのため、スイートの実行に時間がかかることなく、適切なカバレッジを得ることができます.
- このスイートは、独自の JVM で分離されているため、信頼性が高く反復可能であるため、スイートの実行中に他のスイートや人々が共有環境をいじり、テストが失敗することを心配する必要はありません。
- スイート 2 - フル エンド ツー エンド
- スイートは、複数のマシンに展開された完全な環境に対して実行されます
- 環境内の Tomcat にデプロイされた API
- ピア サービスは、実際の「ライブ」の完全展開です
このスイートでは、ピア サービスでデータをセットアップする必要があります。つまり、テストの作成には一般的に時間がかかります。可能な限り REST クライアントを使用して、ピア サービスでデータのセットアップを行います。
このスイートでのテストは通常、作成に時間がかかるため、ほとんどのカバレッジをスイート 1 に置きます。スイート 1 のモックは実際のサービスとまったく同じように動作しない可能性があるため、このスイートにはまだ明確な価値があると言われています。
ご指摘の件につきまして、以下のとおり対応させていただきます。
- ビジネス シナリオを実行する統合テスト ケースを定義する能力。
- cucumber-jvmを使用して、上記の両方のスイートのビジネス シナリオを定義します。これらのシナリオは、ビジネス ユーザーが理解してテストを実行できる英語のプレーン テキスト ファイルです。
- スイートを実行する前に、テスト データを使用して DB をセットアップします。
- 私たちの統合スイートではこれを行いませんが、過去に単体テストにdbunitで unitils を使用したことがあり、非常にうまく機能しました。
- リモート サーバー (Tomcat) で実行されている REST API を呼び出す
- 期待される出力を検証するために、DB ポスト テストの実行を検証します。
- これを簡単にするためにライブラリを使用していないため、ここで推奨事項を提供することはできません。手動で行うだけです。何か見つけたら教えてください。
- REST API のコード カバレッジ レポートを用意して、スイートがカバーするシナリオにどれだけ自信を持っているかを確認します。
- 統合テストのコード カバレッジは測定せず、単体テストのみを測定するため、ここで推奨事項を提供することはできません。
今後、詳細が明らかになる可能性があるため、Techblogに注目してください。