7

私は最近、現在のプロジェクトでフリーランサーとして働き始めました。私が思いついたことの 1 つは、失敗した Jenkins ビルドでした (ここに着手する 1 週間前の 4 月 8 日から失敗していました)。

一般的に言えば、ログには大量の DI 問題が表示されます。私が最初にしたことは、同じアプリケーション コンテキストから始めて、すべてのテストを同じように動作させることでした。彼らはまた、正しく動作しないように見える独自の「モッキング」も実装しました。主任開発者との話し合いの後、Springockito の使用を開始することを提案しました。(特定のモジュールでは、統合テストのためにモックが必要でした -- 従来の理由で、変更できません)

とにかく、その後、物事はひどく失敗し始めました。テストで嘲笑された、単に嘲笑されなかった、または見つからなかったなどの多くの豆。通常、アプリケーション コンテキストの読み込みに失敗し、1 つまたは別の Bean が見つからないことを示します。

私はさまざまなこととさまざまなアプローチを試しましたが、最終的には、すべてのテストに @DirtiesContext を追加するという、私が最も恐れていたことだけがうまくいきました。現在、maven ビルドは再び緑色に変わり始めており、テストは本来の動作を開始しています。しかし、私は毎回Springコンテキストをリロードしています。これには時間がかかります.コンテキストは約1〜2秒でロードされるため、これはすべて相対的です.

この話の補足として、彼らは Hibernate 4 にアップグレードしたため、Spring 3.2 にアップグレードしました。以前は、Spring 3 の古いバージョンを使用していました。当時はすべてのテストが機能しており、@DirtiesContext は必要ありませんでした。

さて、私が最も心配しているのは、この奇妙な振る舞いの説明がすぐには思いつかないことです. @Autowired Bean を使用するテストを起動するだけで、Springs コンテキストが汚れているように見えます。すべてのテストがモックを使用しているわけではないため、そうではありません。これは誰にとってもおなじみの音ですか？Spring (の最新バージョン) との統合テストで同じ経験をした人はいますか?

Stackoverflow で、このチケットを見つけました: How can a test 'dirty' a spring application context? 私が見ている動作をほぼ要約しているように見えますが、要点は、サービス/リポジトリ/...を自動配線していて、それらのクラスにセッターがまったくないということです。

何かご意見は？

ありがとう！

4

1 に答える 1

5

私自身の質問に答えるために、その秘密は Spring バージョンにありました。私たちは Spring 3.1.3 を使用していましたが、彼らは Spring 3.2 を使用していると推測していました (彼らは Spring バージョンの最近のアップグレードについて常に話していました)。

説明はここにあり、それを修正するために私が見つけたブログ投稿です。 /

そして、関連する部分のコピーペースト:

Spring 構成でのジェネリック ファクトリ メソッドの使用は、決してテストに固有のものではありませんが、EasyMock.createMock(MyService.class) や Mockito.mock(MyService.class) などのジェネリック ファクトリ メソッドは、Spring の動的モックを作成するためによく使用されます。 >テスト アプリケーション コンテキストの Bean。たとえば、Spring Framework 3.2 より前のバージョンでは、次の構成では OrderRepository を OrderService に自動配線できない可能性がありました。その理由は、アプリケーション コンテキストで Bean が初期化される順序によっては、Spring が orderRepository Bean のタイプを com.example.repository.OrderRepository ではなく、java.lang.Object であると推測する可能性があるためです。

それで、どうやってこの問題を解決しましたか？さて、私は次の手順を実行しました。

  • 新しい Maven モジュールを作成する
  • モックが必要なテストを除外します。モックされていないすべてのテストは、別の Failsafe 実行で、Spring ビルドで正常に実行されます (基本パッケージ「クリーン」を作成し、そのように並べ替えました)。
  • すべての模擬テストを「mocked」と呼ばれる基本パッケージに入れ、模擬テストのために Failsafe で追加の実行を行います。
  • モックされた各テストでは、Springockito を使用してモックを作成しています。@ReplaceWithMock を簡単に実行するために、Springockito アノテーションも使用しています。モックされたすべてのテストには @DirtiesContext のアノテーションが付けられるため、テストごとにコンテキストがダーティになり、テストごとに Spring コンテキストが再導入されます。

私ができる唯一の合理的な説明は、Spring フレームワークから Spring Bean の管理を引き継ぐフレームワーク (Springockito) があるため、コンテキストが事実上汚れているということです。それが正しいかどうかはわかりませんが、私が思いつく最良の説明です。実際、これがダーティ コンテキストの定義です。そのため、ダーティとしてフラグを立てる必要があります。

この戦略を使用して、ビルドを再度実行し、すべてのテストを正常に実行しています。完璧ではありませんが、機能しており、一貫しています。

于 2013-07-09T18:44:52.743 に答える