私は現在、エンドユーザーと Web サービスの間の一種のプロキシであるアプリケーションを作成しています。
ユーザーがサービスを要求すると、アプリケーションは適切なパラメーター セットを使用して Web サービス メソッドを呼び出し、結果を返します。
何も問題がなかったことを確認するために、プロジェクトの単体テストを作成することにしました (はい!コードを書いてからでは遅いことはわかっています。次回は最初に単体テストを作成します)。
これらの単体テストでは、アクセス許可の例外やサービス関連の例外などが発生していないことを確認するために、Web サービスに対して実際の要求を行う必要があります。したがって、インターフェイスを抽出し、テストのためにサービスをモックすることは役に立ちません。実際の Web サービスを実際に呼び出す単体テストを作成することは許容されますか?
Web サービスで 1 分間に 1 つのリクエストしか許可されない場合、2 つのテストの間に遅延が生じる可能性はありますか?
あなたが話しているのは統合テストです。
Web サービス用にそのようなテストを作成することは問題ではありません。それらは単体テストと同じスタイルで書かれていますが、ライブシステムやその部分をテストしています。テスト コンテキストで Web サービスを開始することもできます。
また、呼び出しの遅延がある状況を制限したり、他の状況をシミュレートしたりするのは、ユーザーとテスト コンテキスト次第です。
私の理解では、単体テストはすぐに結果が得られるはずです。あなたが求めているのは、単体テストではなく、統合テストです。
もちろん、システム全体を統合してテストしているので、単体テストよりも「統合テスト」の方が多いと思いますが、それは受け入れられます。
テストを遅らせるためにできることは、単にThread.sleep(1000)テストの最初に a を入れることです。
Webサービスレイヤーの背後にあるコードをテストするのはどうですか？私が過去に行ったことは、すべての実際のコードが存在するビジネスロジックライブラリへの単なるラッパーとしてWebサービスを使用することです。次に、Webサービス要求の制限を気にせずに、このライブラリで統合テストを実行できます。