マイクロサービスのモックは何か？
私は、マイクロサービスとDockerマルチコンテナーアプリケーションを操作するための開発ワークフローを理解しようとしています。
私が特に解決しようとしていることは、開発に向けた適切な「ライブリロード」ワークフローを取得することです。
例：
私のフロントエンドでは、変更を保存するたびにページを自動的にリロードするwebpack-dev-serverを使用できます。これにより、展開を待つことなく、フロントエンドコードをすばやく簡単に記述できます。
ただし、フロントエンドがREST APIから取得したデータを表示している場合、そのAPIの開発バージョン（それ自体がnodemonを使用してライブでリロードするか、または同様のもの）を実行する可能性があります）またはモックAPI。これは、開発環境のプロキシ構成を使用して、webpackで十分簡単に実現できます。
私のREST API-同様に、他のマイクロサービスをモックしたいと思うかもしれません。たとえば、私のREST APIにPOST =画像を保存するためのエンドポイント-aws-sdkを介してAWS S3バケットに保存します。その機能を模倣したいと思うでしょう。
本質的に-それがどのように見えるか-それはすべての（またはほとんどの）マイクロサービスについてです-私はそれのモックバージョンも作成したいと思います。
私のワークフローが次のようになると想像すると、次のようになります。
- フロントエンドで、画像をバックエンドに送信するボタンを作成します。 POSTリクエストが適切に行われていることを確認します。
- REST APIで、POSTリクエストを受け取るエンドポイントを作成します。フロントエンドボタンをクリックし、バックエンドがそれを受信していることを確認します。
- AWS SDK呼び出しを行うためのバックエンドマイクロサービスを作成します。実際の開発AWSバケットを指すように接続します。 POSTエンドポイントをワイヤリングして、このマイクロサービスにイメージを送信します。フロントエンドボタンをクリックして、S3バケットに入れられることを確認します。
- ただし、この画像の送信は遅すぎるため、AWS SDKサービスのモックバージョンを作成します。 REST APIを代わりに使用するように切り替えます。
- フロントエンドで、「保存された画像」を表示するための機能を記述します。確認メッセージ。
私の質問は：
- これは標準的な方法ですか、それとも私はベースから外れていますか？
- 実際のマイクロサービスを使用しているか、偽のマイクロサービスを使用しているかをすばやく切り替える方法は、Dockerにありますか？
はい、外部サービスのモックアウトは有効なアイデアであり、実際の物理インスタンスなしで変更されていないコードをテストする唯一の方法であることがよくあります。
モック動作は次のとおりであるため、本物のテストインスタンスを使用するほど正確ではありません。
- 外部サービスの実際の動作ではなく、外部サービスの理解
- 外部サービスの変更と更新の遅れ
- 多くの場合テストに関心のある、代表的なタイミングやパフォーマンスへの影響はありません。
これらは、「何かを壊しただけなのか」、「リターンエラーと予期しないエラーを処理できますか」、「外部サービスのパフォーマンスにどれほど敏感であるか」のテストをすばやく実行するための良い方法です。メンテナンスコストを犠牲にして、システムテストの柔軟性とカバレッジを獲得できます。
多くのウェブサイトはそのようなテストの欠如のためにダウンしていますが、コメンテーターがユニットテストを使用して指摘したように、これはこれらのもののテストカバレッジを取得する唯一の方法ではありません。