クライアントにいくつかのエンドポイントを提供するサーバーをセットアップし、バックエンドへのデータへのnode-rest-clientパッケージを使用するクライアントを持っています。post
データがエンドポイントに適切に送信されることを確認して、クライアント側の単体テストを書きたいと思います。
テスト用にダミーサーバーを設置することも考えていますが、それは適切ではありません。
どうすればそのようなテストを達成できますか?
不足しているデータがあれば教えてください。
前もって感謝します！
パッケージを見てきましたがsupertest、これはREST APIサービス自体をテストするために使用され、クライアントからのREST呼び出しをテストするために使用されないようです
ダミー サーバーをセットアップすることは、「受け入れテスト」戦略の一部として正当なアプローチです。単体テストとは異なり、受け入れテストは単一のコンポーネント (多数のユニットで構成される) を分離してテストし、データベースやバックエンド HTTP サービスなどの外部要因をスタブアウトします。クライアント側全体がバックエンド HTTP サービスとどのように対話するかをテストする場合は、ダミー サーバーを使用することをお勧めします。一般に、受け入れテストは単体テストよりも範囲が広く、数が少なく、時間がかかります。そのため、ダミーの HTTP サーバーを起動しても問題ありません。
ただし、サーバーへの呼び出しを行う個々の JavaScript ユニットを本当に単体テストしたい場合は、実際には少し注意が必要です。単体テストで実際の HTTP サーバーを起動したくないのは、実行が遅くなり、並行して実行できなくなるためです。
最適なアプローチは、使用しているテクノロジによって異なります。たとえば、AngularJS は、$httpBackendという HTTP 呼び出しを単体テストする方法を提供します。基本的にはダミーの HTTP サーバーですが、実際には HTTP を経由しません (すべての要求はメモリに残ります)。これが可能なのは、Angular チームがテスト容易性を優先事項と見なし、最初からこのように設計したためです。
node-rest-client が同様の種類のモック HTTP サーバーを提供するとは思わないため、クライアントの単体テストが難しいことが判明する可能性があります。おそらく最良の方法は、node-rest-client のすべての使用をスタンドアロンの JavaScript オブジェクトにラップすることです。このオブジェクト自体には単体テストはありませんが、クライアント側コードの他の部分の単体テストで簡単にモックアウトできます。この単体テストされていないオブジェクトは、別のテスト スイートの一部としてダミーの HTTP サーバーに対してテストできます。または、統合テストを使用して、この部分の問題をキャッチすることもできます。
いつものように、統合テスト (バックエンドの実際のインスタンスに接続する) への依存は最小限に抑えることが最善です。統合テストは遅く、信頼性が低いためです。これらのテストは、パフォーマンス、接続の詳細、構成の互換性など、最上位レベルの詳細を確認するためだけのものであるべきです。
ラッピング アプローチを採用する場合は、単体テストが行われないため、ラッパー内のロジックをできるだけ少なくすることが重要です。
node-rest-client のすべての使用をコード内の 1 か所に限定するため、すべての HTTP 呼び出しを javascript サービス オブジェクトでラップすることは、テスト戦略に関係なく、おそらく良い方法であることに注意してください。