3

次のような JUnit テスト クラスがあります。

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration( locations = { "beanDefinitions.xml"})
public class MyTest {

    @Mocked private SomeDependency usedInSpringContext;

    @Test public void letsTest() {
        ...
    }
}

問題は、JMockit がモックする機会を得る前に、Spring ランナーがその Bean をロードすることです。それを避ける方法は？これは JMockit 1.0 と Spring 3.07 です。beanDefinitions.xml を変更しない方がよいでしょう。

テスト対象のコードはレガシーです。簡単に取り除くことができないハードコーディングされた多くのスプリング依存関係が含まれています。したがって、最初のステップ - 嘲笑。

4

2 に答える 2

2
于 2013-02-05T18:39:15.083 に答える
0

Springと一般的な依存性注入の優れた点の1つは、依存性を満たすためにクラスがコードで乱雑にならないことです。彼らはただ座って、他の誰かが共同作業するオブジェクトを埋めるのを待ちます。したがって、モックオブジェクトをプラグインするのは簡単なことです。

// no Spring runner or context configuration
public class FooTest {
    Foo foo;

    @Before
    public void setup() {
        foo = new Foo();
        foo.setDependency(mock(dependency)); // details depend on mocking framework
    }
}

このアプローチでは、テストしているオブジェクトを自動配線したり、注入したりすることはありません。少なくとも、モックコラボレーターに向けて再構成する場合はそうです。テスト対象のコードに多くの依存関係がある場合、大量のセットアップコードが発生する可能性がありますが、これは正常なことです。

確かに、一部のもの（データベースなど）はモックするのが難しいため、SQLクエリ（たとえば）が意図したとおりに動作することを確認するには、別のテストアプローチが必要です。これは、次のようなものを含む別のBean定義ファイルから始まります。

<jdbc:embeded-database id="datasource"/>

詳細については、 http：//static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/testing.htmlを参照してください。

トリッキーな部分は、JUnitテストをずっと書いていなかった場合、すべてのBeanが他のすべてのBeanに依存しているように見える状況に陥った可能性があることです。したがって、テストしようとしている「ユニット」は1つのクラスではなく、相互に関連する一連のクラスです。その場合は、Bean定義ファイルを小さな部分に分割してから、各部分の単体テストを作成することをお勧めします。

このアプローチでは、Spring構成がユニットの一部であるため、Springにテスト対象のコードを配線させることができます。ユニットテストコードは、そのユニットの外部の依存関係をモックしてプラグインします。

実際のbeanDefinitions.xmlファイル全体を使用することを主張する場合は、単体テストではなく統合テストを作成していることになります。

于 2013-02-05T23:20:28.540 に答える