2017-02-08 10 views
3

私は、テスト対象のクラスをインスタンス化し、そこに存在するかもしれないモックを注入するために、mockitoの@InjectMocksを使用する単体テストのスイートを持つSpringブートプロジェクトを持っています。言い換えれば@AjectWockと組み合わせた@Autowire

私はこの

@InjectMocks のMyClass MyClassのを持っている場合。

それから私は)(

MyClassのMYCLASS =新しいMyClassのを必要としません。
または @Autowired MyClass myClass;

これまでの設定は正常に機能しました。

しかし、最近では、テストを実行するときにプロジェクトのスプリングブートプロパティにアクセスする必要があります。つまり、@Autowire(Environmentクラスをインスタンス化するものを含む)のインスタンスが動作するように、テスト内でSpringBootタスクランナーを使用する必要がありました。

@InjectMocksを使用してクラスをインスタンス化すると、クラス内の@Autowiredのインスタンスが動作しないことがわかりました(作成するオブジェクトはnullです)。つまり、Environmentクラスはなく、Springプロパティへのアクセスはありません。

は、代わりに私が@InjectMocks注釈

ので、この

@InjectMocks のMyClass MyClassのに@Autowiredを追加する必要があります。

この

@Autowired
@InjectMocks MyClassのMYCLASSなります。

私の質問は簡単です。 これには何か問題はありますか? myClassをインスタンス化したり、グリッチを引き起こす可能性のあるものを二重にしますか?

答えて

4

春に属するアノテーションとMockitoに属するアノテーションを混在させていると思います。

ウェブアプリケーションを実行するだけで、@Autowiredはクラスに特定の依存関係を提供します。この方法では、newキーワードを使用して手動でオブジェクトを作成する必要はありません。しかし、実行時には、再生中の春の注釈だけです。 mockitoアノテーションは、このユースケースのためのものではありません。

テストを実行しているときは、逆の方法です。今では春のアノテーションは何もしません、それは動作しているmockito注釈です。 @InjectMocksは、「私が@Mockで提供したもので、このクラスで必要とされているものは、そこに貼り付けてください」とmockitoに伝えます。たとえあなたがそのフィールドに@Autowiredを入れていなくても、それは行います。 Mockitoは春の注釈を気にしません。

@Autowiredと@InjectMocksを同じ場所に置くユースケースはありません。テストでは、アプリケーションのロジックとモチートのアノテーションにバネアノテーションを使用します。

答えはかなり抽象的ですが、あなたの質問もそうです。より具体的なヘルプを得るには、a minimal, complete and verifiable exampleを提供する必要があります。