Angular アプリ (Angular 1.1.5) を開発しています。e2e テストの REST API 応答をモックする何らかの方法が必要です。
AngularJS (Green & Seshadri)では、 HTTP リクエストの単体テストについて詳しく説明していますが$httpBackend、e2e テストについてはほとんど触れていません。
ドキュメントでは、ngMockE2Eモジュールを使用してモックすることを提案しています$httpBackend(これは、通常の単体テストの$httpBackendモックとは異なります。
API を調査するのに数時間を費やしましたが、ngMockE2Eいくつかの利点が見られますが、多くの欠点があるようです。私の質問は：
ngMockE2Eテスト応答を提供する単純なサーバーよりも優れている点は何ですか? または、より一般的には、サーバーとAngularアプリの相互作用をテストする最良の方法は何ですか?
いくつかの欠点を考えることができます：
ngMockE2EHTML を変更して、別の Angular モジュール (実際のアプリケーション モジュールに依存する新しいモジュール) でアプリをブートストラップする必要があります。- Firebug/Developer ツールが検査する HTTP リクエストはありません。これは私にとって大きなものです。最終的に、モック バックエンドでリクエスト/レスポンス ロギング メソッドを作成しました。ほとんどのモック バックエンドには、この種のコードが含まれていると思います。
- URL からパラメーターを抽出する簡単な方法はありません。からidパラメータを取得し
/resource/:idたい場合は、URL ( ) に一致する正規表現を指定してから\/resource\/.+$、一致する URL 文字列をスラッシュで分割し、最後の要素を選択する必要があります。 - API は扱いにくいです。静的オブジェクトを返すのは簡単ですが、要求された URL に基づいて返すテスト オブジェクトを動的に決定するのは困難です。アプリによっては、テスト URL の完全なセットをハードコードできる場合がありますが、多数のリソースをテストする必要があるため、これは非現実的です。より複雑なコードは、より多くの間違いがあることを意味します。
メリットも考えられます。使用時ngMockE2E：
- テスト API の場所をアプリに伝える必要はありません。すべてのHTTP リクエストが一致
$httpBackendするか検査します。 - Web サーバーを実行する必要はまったくありません。
- テスト データへの変更を取得するためにサーバーを再起動する必要はありません。
- テストの全体的なコンポーネントが少なくなります。ただし、これが統合テストであることを考えると、これは大きな利点ではありません。
思考や経験に非常に興味があります。