は、以下の「生産」のコード考えてみましょう:これは私が直面しています実際の状況に基づいています@Tableクラスのコンストラクタに@Injectableクラスオブジェクトを適用するにはどうすればよいですか?
public class Foo<T extends Number> {
private Bar delegate;
private Class<T> numberClass;
public Foo(Class<T> numberClass) {
this.numberClass = numberClass;
}
public T doSomething() {
if (numberClass==Integer.class) {
return delegate.getIntValue();
} else if (numberClass==Float.class) {
return delegate.getFloatValue();
} else if (numberClass==Double.class) {
return delegate.getDoubleValue();
} // etc etc etc
return null;
}
}
を...私は、デリゲートオブジェクトの実装を制御することはできません。
このクラスをJMockit @Tested
注釈でユニットテストするにはどうすればよいですか?私は@Injectable
を使用してClass
の値を注入することはできません... Class
はモック可能ではないと訴えています。そして、私はそれを嘲笑しようとしていない、それを注入するだけです。私が@Injectable("foobar") String s;
と言うことができ、非擬似注射可能オブジェクトを得ることができるストリングまたはプリミティブまたは列挙型とは異なり、これらのセマンティクスはClass
オブジェクトには適用されません。
明らかに、私の回避策は@Before
メソッドで私のFoo
を手作業で作ることです。しかし、私はこの状況がJMockitで可能であるべきだと感じることはできません。
私は制限とその理由を理解します。私はちょうどコンストラクタを作る方法を頼んでいると思う* mocking *せずに注入*。皮肉なことに、フィールド注入は(Deencapsulationを使って)もっと簡単になるでしょう... – dcsohl
私は上記の私の例は、モックなしでコンストラクタを実行すると主張します。すべての '@ Tested'と' @ Injectable'アノテーションが実行しているのは、注入可能な変数と一致するコンストラクタと指定された値を使ってFooをインスタンス化することです。しかし、注射可能な変数は実際には[jmockit api](http://jmockit.org/api1x/mockit/Injectable.html)によると、実際に模擬されたインスタンスです: "そのようなインスタンスは、モックされたオブジェクトとは対照的に、適切なモックオブジェクトといえます通常の@Mockedタイプのインスタンスです。 "上記の私の例で行われている嘲笑はBarクラスだけです。 – TheEllis
また、望ましくない場合でもBarクラスを模倣する必要はありませんが、これはユニットテストではなく統合テストになります。 – TheEllis