2

JavaJAX-WSを使用してサービスを作成するスタンドアロンのJavaアプリがあります。サービスをテストするためのテストケースを作成したいのですが、どうすればよいですか？

プロジェクト外で外部クライアントを使用することを考えましたが、これが最良の方法ですか？

4

3 に答える 3

5

厳密に言えば、Web サービスをデプロイしてテストすることは、単体テストではなく統合テストです。そうは言っても、これを単体テストする方がおそらく良いでしょう。ビジネス ロジックを実装する別のレイヤーと、それを Web サービスとして公開する別のレイヤーを作成します。その後、Web サービスについて心配することなく、ビジネス ロジックをテストできます。

結局のところ、Web サービスを開始するために使用している Web フレームワークをわざわざ再テストしたくないでしょう。ビジネスロジックを本当にテストしたいのです。これにより、より高速で壊れにくいテストを作成できます。

于 2012-05-21T22:01:56.973 に答える
3

統合テストと単体テストに関する議論は、延々と続く可能性があります。Web サービス レイヤーを削除して内部のビジネス ロジックをテストするだけでは、統合テストが単体テストに変わりません。

IMHO Web サービスはアプリケーションのパブリック API であり、アプリケーションのバージョン間で一貫して動作する必要があります。したがって、通常のクライアントであるかのようにアプリとデータベースをヒットする、大規模な soapUI テスト スイートをお勧めします。アサーションを追加して、予想される成功と失敗のメッセージを確認できます (誤ったデータがスローされたときに Web サービスがどのように動作するかをテストすることを忘れないでください)。また、Groovy assert を追加して、各 Web サービスの呼び出し後にデータベースの状態を確認することもできます。

上記を補完するために、単体テストを迅速に実行することを強くお勧めしますが、夜間のビルドに対して堅牢な統合スイートを毎晩実行することで、API の品質が保証され、顧客がヒットし始めたときにのみ洗い流される多くの問題を回避できます。アプリがデプロイされたときのサービス。

Web サービスには UI がないという性質があるため、人間のテスターに​​任せると十分にテストされません。

于 2012-05-21T22:43:08.403 に答える
1

実際の Web サービス エンドポイントやクライアントをテストするとは思いません。すべてのビジネス ロジックを何らかのサービス レイヤーに移動し、それらのオブジェクトの単体テストを行います。例えば：

 @Path("/user")
 public class UserWebService {

   @Inject
   private UserService userService;

   @Path("/delete")
   public void deleteUser(@RequestParam long id) {
      userService.deleteUser(id);
   }

 }

次に、UserService の実装を単体テストします。

于 2012-05-21T21:58:32.353 に答える