JUnit 3 では、テストは同じ Spring コンテナー内で実行されますか? または、各テストは独自のコンテナーを取得しますか?
テストから他のテストへのセッション データの「流出」を防ぐにはどうすればよいですか?
JUnit 3 の詳細はわかりませんが、JUnit 4 にアップグレードすることをお勧めします。
ここで、@ContextConfiguration
(または@WebAppConfiguration
) を使用して使用するアプリケーション コンテキストを指定し、SpringJUnit4ClassRunner
を使用してテストを実行すると、テスト間でキャッシュされます。参照ドキュメントから:
TestContext フレームワークがテストの ApplicationContext (または WebApplicationContext) をロードすると、そのコンテキストがキャッシュされ、同じテスト スイート内で同じ一意のコンテキスト構成を宣言する後続のすべてのテストで再利用されます。キャッシュがどのように機能するかを理解するには、一意のテスト スイートの意味を理解することが重要です。
ApplicationContext は、それをロードするために使用される構成パラメーターの組み合わせによって一意に識別できます。したがって、設定パラメータの一意の組み合わせを使用して、コンテキストがキャッシュされるキーが生成されます。
リファレンス ドキュメントには、コンテキスト キャッシュ キーの作成に使用される構成パラメーターが引き続きリストされています。
「ブリーディング」とはどのようなセッション データですか? アノテーションを使用し@Transactional
て、データベースに書き込む test のデータベース変更をロールバックします。注釈は@DirtiesContext
、現在のアプリケーション コンテキストが汚染された場合に再作成するために使用できますが、通常は別の を指定することで回避できます@ActiveProfiles
。Spring の統合テスト アノテーションの詳細については、リファレンス ドキュメントを参照してください。