我々は最終的に我々はまた、JUnitの3でJMock 2.不足
を多用するのJUnit 3からのJUnit 4に私たちのユニットテストコードベースを移行している、JMockは便利を提供します（MockObjectTestCase）は、JunitのTestCaseのサブクラスであるだけでなく、モックフレームワークに関するさまざまなハウスキーピング任務を処理します。テストクラスでは、人生はかなり簡単になります。
JUnit4では、JMockはそのようなサポートを提供していません。あなたのテストクラスは手動でMockeryオブジェクトを作成しなければならず、正しいテストランナーアノテーションを使用することを忘れてはなりません。また、すべてのモック関連操作をMockeryに委譲する必要があります。要するに、JUnit 3のテストに必要だったよりも、テストクラスにはるかに多くの責任があります。
ここで、JUnit4の魅力の一部は、何かをサブクラス化する必要がないことに感謝しますが、このJMockの状況は後退のように見え、必要以上に多くの作業を3から4に移植します。
何か不足していますか？ JUnit4/Jmock2テストクラスを手作業ですべてのクラスに追加しなくても、実際にはJUnit4/Jmock2テストクラスを書くのにいい方法がありますか？もちろん、私自身のサポートベースクラスを書くこともできますが、JMock2 APIからこのような明白な省略があるように見えますが、私がこの点を逃してしまったのか疑問に思います。
編集：
@RunWith(JMock.class)
public class JMockSupport {
protected final Mockery mockery = new Mockery();
protected void checking(ExpectationBuilder expectations) {
mockery.checking(expectations);
}
protected <T> T mock(Class<T> typeToMock) {
return mockery.mock(typeToMock);
}
protected <T> T mock(Class<T> typeToMock, String name) {
return mockery.mock(typeToMock, name);
}
protected Sequence sequence(String name) {
return mockery.sequence(name);
}
protected void setDefaultResultForType(Class<?> type, Object result) {
mockery.setDefaultResultForType(type, result);
}
protected void setImposteriser(Imposteriser imposteriser) {
mockery.setImposteriser(imposteriser);
}
protected void setNamingScheme(MockObjectNamingScheme namingScheme) {
mockery.setNamingScheme(namingScheme);
}
protected States states(String name) {
return mockery.states(name);
}
}
これはちょうど嘲笑にエコーJUnit3 MockObjectTestCaseクラスが定義されたメソッドのすべてが含まれています。ここでは、オプションのサポートクラスがどのように見えるかのソースコードです。 @RunWithアノテーションは、テストクラスに追加することを忘れる可能性を避けるためにもあります。
私は、構成がはるかに柔軟ではないことに同意しますが、継承は利便性をもたらします。それは選ぶことができてうれしいです。 – skaffman
記録のために、私はJMockリポジトリに@Ruleコンテキストを実装しました –