私は最近、重大な JUnit テストの問題を抱えるグループに参加しました。問題の 1 つは 8 分間のテストです。テストにはいくつかのセクションがあります。それぞれが org.springframework.context.ApplicationEventPublisher.publishEvent() に続いてさまざまな時間の Thread.sleep() を呼び出し、条件をテストします。
このアプローチには明らかな問題がいくつかあります。Thread.sleep() 呼び出しのタイミングが脆弱です。
ビジー状態のマシンではテストが失敗することがあります。と
テストが失敗しない場合、テストに非常に時間がかかりすぎます。
これらのイベントが処理されるプールはテストのためにアクセス可能ですか? また、イベント カスケードが停止したかどうかを確認するための呼び出しはありますか?
言及する価値があるのは、実際に外部サービスを呼び出すテスト コードは統合テストであり、単体テストではないということです。ここで本当に単体テストを行っている場合は、これらの呼び出しをモックに置き換える必要があります。これにより、ビジネス ロジックに返される値をより適切に制御し、特定の条件をテストできます。また、これまで見てきたように、これにより、外部の (コード以外の) 状況による誤検出がほとんどなくなります。明らかに、これらのテストは失敗していません。彼らが使用することを期待している機能です。
applicationEventMulticasterこの Bean ID をアプリケーション コンテキストに追加することで、デフォルトを上書きできます。
デフォルトの の代わりに、SimpleApplicationEventMulticasterこの Bean に TaskExecutor を設定して、複数のスレッドで非同期に発行するイベントを実行できます。
または、独自のマルチキャスターを実装することもできます。これは、どのイベント リスナーがどのくらいの時間、どのイベントで、どのくらい時間がかかったか、またはブロックされていたかを出力します。これは、8-Minute-Testcase の実際の問題を追跡するのに役立ちます。
興味深いことに、ApplicationContext を使用しているときに Spring によってデフォルトで使用される SimpleApplicationEventMulticaster の JavaDoc には、次のように記載されています。
デフォルトでは、すべてのリスナーが呼び出しスレッドで呼び出されます。これにより、不正なリスナーがアプリケーション全体をブロックする危険性が許容されますが、最小限のオーバーヘッドが追加されます。代替の TaskExecutor を指定して、リスナーを別のスレッド (スレッド プールなど) で実行します。
私は（意図的に）Spring を避けているので、詳細を説明できるかどうかはわかりませんが、睡眠の問題を見るだけで、WaitFortempus-fugit（恥知らずなプラグ）のようなものを使用してCondition、「睡眠と希望」ではなくポーリングすることができます。 . これは理想的ではなく、通常は (前に提案したように) テスト方法を変更することが望ましいですが、競合状態や不安定なテストを回避し、一般的にテストを高速化する可能性が高い、よりきめ細かい「待機」が得られることを意味します。
詳細についてはプロジェクトのドキュメントを参照し、役立つと思われる場合は投稿してください。