次のような構造の方法があります。
method1(Object obj,byte[] myarray)
{
mymanager.dbcall1();
mymanager2.dbcall2();
}
ここで、dbcallを実行しているこれらのマネージャーを実際にモックできるJUNITテストケースを作成したいと思います。最後に、結果を比較したいと思います。これらのマネージャーは、アプリケーションの実行時にのみ使用できます。
テストしmethod1()
ますか?もしそうなら、私はあなたがmymanager
囲んでいるクラスにセッターを持っていると思います、それはあなたが(Mockitoを使って)あなたを可能にするでしょう:
@Before
public void setUp()
{
MyClass my = new MyClass();
MyManager mgr = mock( MyManager.class );
my.setManager( mgr );
// Similar for mymanager2
}
次に、のすべてのメソッド呼び出しはmgr
nullを返します。他の戻り値が必要な場合は、doReturn(...).when( mgr ).dbcall1()
構成を使用できます。
乾杯、
さあ、スタックオーバーフローを検索したところ、誰かが以前に尋ねたことのあるものがほとんど見つかりました。
これはEJBに基づいていますが、現在何を使用しているかはわかりませんが、これにはいくつかの共通の原則がある可能性があります。
まず、依存性の注入が必要になります。これを実現する方法はたくさんありますが、簡単な方法は次のとおりです。
private I_DatabaseManager mymanager = null;
method1(Object obj,byte[] myarray)
{
getDatabaseManager().dbcall1();
getDatabaseManager().dbcall2();
}
private I_DatabaseManager getDatabaseManager() {
if (mymanager == null) {
return getProductionImplementationOfDatabaseManager();
}
return mymanager;
}
protected void setDatabaseManagerImplementation(I_DatabaseManager newImplementation) {
mymanager = newImplementation;
}
次に、テストコードで、I_DatabaseManagerインターフェイスを実装するモッククラスを作成し、このモック実装をテストに設定できます。