4

コンテナ内のテストは、多くの場合、モックオブジェクトを使用したテストとは対照的です。ただし、モックオブジェクトは実際のオブジェクトの動作を模倣しているだけなので、コンテナ内のテストは、実際の環境でシステムを実際にテストする唯一の方法ではありませんか？

コンテナ内のテストとモックオブジェクトの部分的な代替手段として、SpringはTestContext、実際のアプリケーションコンテナ（私の場合はWebアプリケーションサーバー）を起動することなく、Springを適切に初期化するフレームワークを提供します。ただし、これは、アプリケーションサーバー固有の機能がサポートされていないのに、Spring固有の機能のみを初期化するため、多少制限されたアプローチです。したがって、すべてをテストすることはできません。また、実際のWeb実行で使用されるデフォルトと100％同じWebApplicationContextではないので、このアプローチは少しハッキーではありませんか？悪いですか？

コンテナ内のテストには、少なくともCactus（時代遅れ）、Jeeunit（非常に小さなプロジェクト）、JBoss Arquillian（まだアルファ版ですが、有望に見えます）があります。これらのプロジェクトはあまり広く使われているとは思わないので、コンテナ内のテストに何か悪い点はありますか？コンテナ内テストでよく言及される主な欠点は、実行速度が遅いことです。ただし、継続的インテグレーション環境で比較的小規模なプロジェクトで実行する場合、これは問題にはなりません。

要約すると、コンテナ内またはコンテナ外のテストを行う必要があり、その理由は何ですか？統合テストにモックオブジェクトまたは代替の初期化メカニズム（Spring TestContextなど）を使用すると気分が悪くなりますか？

サブノート：私は最近、統合テストの分類について質問しました。これは関連する可能性があります。

4

2 に答える 2

3

しかし、モック オブジェクトは単に実際のオブジェクトの動作を模倣するだけなので、実際の環境でシステムを実際にテストする唯一の方法はコンテナー内テストではないでしょうか?

短い答えはイエスだと思いますが...「統合テストの分類」の質問は非常に関連性があると思います。単体テストと統合テストはどちらも重要ですが、機能は異なります。

単体テストはコードと密接に関連しており、起動と実行が非常に高速である必要があり、コードを反復する開発者が頻繁に実行する必要があり、通常はモックを高度に使用します。アイデアは、依存関係や統合ポイントではなく、問題のコードをテストすることです。単体テストをすべてコンテナー内に作成することの問題は、実行頻度が少なくなったり、開発者の時間を浪費しすぎたりすることです。

コンテナー内/統合テストは、コード プロジェクトに依存する別のプロジェクトの別の場所に分離しました。これらは、本番環境の構成を可能な限り模倣するように設計されています。これらのテストは、セットアップに時間がかかり、実行に時間がかかり、 Cruisecontrolなどで実行するとより便利です。特にリリースが近づいているときや開発が安定した後は、手動で実行されます。昼食時や会議の際に統合テストを起動することがよくあります。統合テストでバグが発見されると、モックでバグを実証する単体テストを作成しようとしますが、これは多くの場合困難であり、不可能な場合があります。

通常、スプリング配線が機能することを確認するため、またはいくつかの基本的な機能をテストするためだけに、単体テストを含むいくつかの小さなコンテナー内テストを行いますが、残りの統合テストは別のプロジェクトで行われます。

とはいえ、両者の間に明確な違いはありません。大量のデータを処理するだけで時間がかかる単体テストを統合テストに移動することもあれば、統合テストが十分に高速に実行され、コードと一緒に含めるのに十分な価値がある場合もあります。

于 2010-07-14T13:00:04.990 に答える
2

I'd say we should do both in-container and out-container testing. The main problem I've found with testing in-container is it's much more work to automate everything. You can get some cheaper wins with something like Spring's integration testing support, but we shouldn't fool ourselves that this covers everything that testing in deployment container would.

On the topic of mocks, I find that they can play a part in integration testing with Spring, but I'm more likely to use fake/stub services with canned results for integration and in-container testing (which I'd call system testing).

If you're not sure on what the difference is between mocking and stubbing, check out this Martin Fowler article.

于 2010-07-14T12:41:33.343 に答える