0

A と B という 2 つのアプリケーションがあり、API を介して互いに通信しています。現在、A のキュウリ テストを作成しています。2 つのオプションがあります。

  1. API が B に送信されるかどうかをテストし、B からの応答をスタブするだけです。

  2. AからBにテストデータをセットアップし(私はAをテストしているため)、実際のリクエストをBに送信し、VCRでリクエスト/レスポンスを記録します

私はオプション 1 を好みますが、同僚は、システム (A と B を含む) が機能していることを確認するには、少なくとも 1 つの実際の要求が必要であると言っています。

私の懸念は次のとおりです。

  1. A のテストから B のテスト データを準備するにはどうすればよいですか?

  2. それらを混ぜ合わせるのは壊れやすいです.Bで変更されたものはすべてAで失敗する可能性があります.

コメントはありますか?

4

2 に答える 2

0

ほとんどのテストでは、要求/応答をスタブ化して、オフラインのときにテストが成功するようにします。

1 つのテストとして、外部サービスがスタブとモックの指示どおりに動作しているかどうかの簡単なテストを行います。

EG get リクエストを実行しても、モックが有効であることを保証するために必要な属性を含む JSON が返されます。

ほとんどの場合、外部サービスの「稼働時間」はテスト スイートで監視するべきではありません。期待どおりに動作するというだけです。

稼働時間の問題については、Nagios、Pingdom、Pagerduty などで sysadmin 側を確認する必要があります。

于 2012-08-22T07:56:36.923 に答える
0

きゅうりのテストを書いているということは、それが統合テストであることを意味します。統合テストでは、何もモックしない方がよいでしょう。これは、アプリケーションを保存しておくための最後の安全ガードです。

したがって、実際のリクエストを最後に 1 回送信して、リクエストが正しいことを確認し、いつでもこの実際のリクエストを繰り返すことができるようにすることをお勧めします。

解決策1の問題:

  1. B変更APIの実装を確認できません
  2. Aが正しいパラメータをBに送信することを確認できません
  3. 複雑なリクエストをモックするのは難しい

したがって、B 用のサンドボックス アプリを作成し、実際にリクエストすることをお勧めします

于 2012-08-26T14:07:10.453 に答える