2011-10-21 7 views
3

java.net.URLを介してWebサービスを呼び出すサーブレットクラスの単体テストを記述します。URL呼び出しを行うサーブレットのユニットテスト

私はMockHttpServletRequest、MockHttpServletResponseを作成し、doGetメソッドにこれらを渡し、すなわち、(JUnitの上の実用的なプログラマのテキストからの技術を使用して)簡単にサーブレットのdoGetメソッドに送信するモックリクエストとレスポンスのオブジェクトを作成することができます。

私が困っている部分は、サーブレットで開いているURLです。

今は、URLを開き、文字列(実動コード)を返し、それを返す関数を呼び出す関数を呼び出すと、固定URLの文字列が直接返されますテストコードが表示されないようにしたいと思っています。ネットワークアクセスを行う関数と直接文字列を返す関数の間の選択は、doGetに対して透過的でなければなりません。

私はこれを達成するためにいくつかの方法を考えることができますが、どれも正しいとは感じません。

  • 例1:関数をtestOnブール値とsetTestModeメソッドを持つクラスにラップします。 junit initは、testModeをtrueに設定できます。デフォルトはfalseです。 testOnはどのメソッドを呼び出すかを決定します。否定的なことは、私は新しいクラスが必要だということです。手に入らないように思われます。

  • 例2:ネットワークアクセスを実装する2つのクラスがあり、そのうちの1つはモックです。 junitにモッククラスをリロードし、プロダクションコードが正規のクラスをロードする(または何とかプロダクションクラスをモッククラスに再マップする)。否定的な考え方:これがどうやって行われるかわからない。不器用に思える。

  • 例3:モックを使用するかどうかを示す静的フィールドを持つクラスを持ち、フィールド値に基づいてサーブレットのURLアクセスを条件付けします。負:グローバル変数のように感じます。

  • 例4:URLを拡張すると、URLだけに切り替えるとプロダクションコードが正常に動作するようになります(ただし、java.net.URLは最終的です)。

私は検索の朝までに正しい答えを見つけることができませんでした。したがって、私はSOの集団知恵に変わりました。

おかげで、 アドナン

PS - 私は同等だ何も動作しますが、私はのjava.net.URLを使用する必要がないことを言及する必要があります。

答えて

3

2番目のオプションは「正しい」オプションです。外部URLへの呼び出しは、サービスにカプセル化する必要があります。サービスは、それを使用するサーブレットに注入されます。これはInversion of Controlが便利な場所です。

あなたのユニットテストでは、実際の実装で注入するテスト実装を注入します。これは、サービスのセッターを提供し、実装を「本当の」ものにデフォルト設定することと同じくらい簡単です。

この種のものは、IoC/DIの標準的な例です。

+0

tomaszとdaveさんに感謝します。検索の途中でIoCへの参照がありましたが、接続できませんでした。私は戻って、もう一度チェックします - あなたが知っているかもしれない高品質のチュートリアルへのリンクを歓迎します。 – adnan

+0

@ user453026私はおそらく、 "制御の逆転"または "依存性注入"と "チュートリアル"を検索しようと思います...それらのほとんどは、検索の際にフレームワーク固有です。しかし、それらのほとんどは、基本的なフレームワークを理解しなくても、基本を視覚化するのに役立ちます。 –

2

あなたは車輪を再発明しているように見えますが、あなたは再びそれを発明しました。例2。これは、通常、依存性注入を使用して実装されており、現時点でソフトウェア開発者がこれまでに考え出した最高のソリューションです。

インターフェイスの背後にあるWebサービスコールを非表示にします。ある実装は実際の呼び出しを行い、もう一方は設定可能なモックです。 DIフレームワーク(Spring、Guice、EJB/CDI)を使用していない場合は、実動実装を模擬テストで手動で置き換えてください。

関連する問題