開発プロキシと単体テスト

開発プロキシと単体テストは、テスト戦略のさまざまな目的に対応します。 どちらも重要ですが、基本的に異なる方法でアプリケーションをテストします。 それらを組み合わせて使用すると、アプリケーションの動作を包括的にカバーできます。

さまざまなテスト方法

単体テストでは 、モックされた依存関係を使用して分離されたコードをテストします。 API を呼び出すコードの単体テストを記述するときは、通常、HTTP クライアントをモックして定義済みの応答を返します。 この方法では、コードが特定のシナリオを正しく処理することを確認できます。

開発プロキシは 、シミュレートされた API 動作を使用して実行中のアプリケーションをテストします。 開発プロキシは、コードをモックする代わりに、実際の HTTP 要求をインターセプトし、エラー、調整、待機時間などの実際の状態をシミュレートします。 この方法では、コードと API の間のすべてのレイヤーを含め、アプリケーション全体をテストします。

それぞれをいつ使用するか

次の場合に 単体テスト を使用します。

  • 特定の関数の動作とエッジ ケースをテストする
  • 分離してビジネス ロジックを確認する
  • 開発中に迅速なフィードバックを得る
  • 高いコード カバレッジを実現する
  • 特定のエラー処理パスをテストする

次の場合は 、開発プロキシ を使用します。

  • 実行中のアプリケーションをエンド ツー エンドでテストする
  • 調整やネットワークの問題など、再現が困難な条件をシミュレートする
  • すべてのレイヤーで実際の再試行ロジックとエラー処理をテストする
  • ランダムなエラーが発生した状態でアプリケーションを読み込み中に実行する
  • コードを変更せずに回復性を確認する

開発プロキシの利点

開発プロキシには、従来のモック作成アプローチよりもいくつかの利点があります。

  • コードの変更は必要ありません。 開発プロキシを使用するようにアプリケーションを変更する必要はありません。 ネットワーク レベルで動作し、HTTP 要求を透過的にインターセプトします。
  • 任意の HTTP ライブラリで動作します。 一部の HTTP ライブラリは、モックするのが難しいことで知られている。 開発プロキシでは、使用するライブラリ (RestSharp、HttpClient、Axios など) は関係ありません。 開発プロキシは、ライブラリに関係なく、すべての HTTP トラフィックをインターセプトします。
  • 実際のアプリケーションをテストします。 モック HTTP クライアントを使用した単体テストでは、実際の再試行ロジック、接続処理、またはタイムアウト動作はテストされません。 開発プロキシは、すべての依存関係を使用して実際のアプリケーションをテストします。
  • エラーを理解しやすくなります。 実行中のアプリケーションで必要に応じてエラーをトリガーできる場合は、アプリケーションでエラーを処理する方法を理解してデバッグする方が簡単です。
  • 複雑な条件をシミュレートします。 開発プロキシは、負荷がかかっているランダムな障害、段階的な調整、断続的なネットワークの問題など、モックを使用して再現できない条件をシミュレートできます。

補完的なテスト戦略

最も効果的な方法は、両方のテスト方法を組み合わせたものです。

  • ロジックには単体テストを使用します。 ビジネス ロジック、データ変換、および特定のエラー処理コード パスを確認するための単体テストを記述します。
  • 回復性のために開発プロキシを使用します。 開発プロキシを使用して、アプリケーションが実際の API 条件 (調整、エラー、低速応答) を正しく処理することを確認します。
  • CI/CD で両方を使用します。 コミットごとに高速なフィードバックを得るための単体テストを実行します。 デプロイ前に回復性の問題をキャッチするには、統合テストで開発プロキシを使用します。

単体テストでは、コードが正しいかどうかを確認できます。 開発プロキシは、アプリケーションに回復性があるかどうかを通知します。 両方が必要です。

次のステップ

カオス テストとは

  • Last updated on