ほとんどの人が EJB をテストするために組み込みコンテナ技術を好んでいるので、それはばかげた質問かもしれませんが、私は経験が不足しているため、これを明確にする必要があります。また、埋め込みコンテナーは、実際のアプリ サーバーに展開する実際の状況を再現できないと主張する人もいます。では、ejb3 をテストするときに、スタンドアロン コンテナーではなく組み込みコンテナーを使用するように指示されているのはなぜですか? 前もって感謝します。
3 に答える
時間。
通常、本格的なアプリケーション サーバーで EJB をテストすると、アプリが原因で多くの時間がかかります。サーバーは、変更が行われるたびに「スピンアップ」する必要があるため、多くの時間が無駄になります。そのため、 OpenEJBなどの組み込みコンテナーを使用すると、多くの時間を節約できます。Embedded Glassfish も最近のオプションですが、個人的には試していません。
ゼロ ターンアラウンドは、Java EE の一種の聖杯です。
これが私が見つけた最も関連性の高い議論です。この横にコメントするか、埋め込み可能なコンテナーと実際のアプリケーション サーバー コンテナーを使用したテストについて独自の理由を追加してください。ありがとうございました。
- 組み込みコンテナーのテスト手法を使用すると、柔軟性が確保されます (新しいライブラリをクラスパスに追加するだけで済みます)。私が理解している限りでは、複数のアプリケーション サーバーにテスト プロジェクトを配信できるようにするためには、テストの実装でアプリケーション サーバー コンテナーに縛られないようにする必要があります。一部のアプリサーバーは、特定の注釈またはデプロイメント記述子を使用できます。それらが使用されている場合、アプリサーバーにバインドされます
- 埋め込まれたコンテナーは軽量です。つまり、テストの実行時間が短縮されます。実際のアプリケーションサーバーは、自動的に開始および停止することが困難であるか、ハングアップする可能性があります。そのため、実際のアプリ サーバーを使用して完全に自動化されたテスト プロセスを構築するのは難しすぎる可能性があります...
- もう 1 つの問題は、ほとんどの Java EE アプリケーションのステートレスな性質です。トランザクション境界 (ステートレス セッション Bean など) のメソッド呼び出しの後、すべての JPA エンティティが切り離されます。クライアントはその状態を失います。これにより、クライアントとサーバーの間でコンテキスト全体をやり取りする必要があります-負荷が高く、クライアントの状態のすべての変更をサーバーとマージする必要があります
- 組み込みコンテナーでは、すべてを実行する 1 つのプロセス (テストと ejbs) があり、実際のアプリ サーバーでは 2 つのプロセス (AppServer とテスト) を調整する必要があります。
- もちろん、完全なテストを行うには、実際のアプリケーションサーバーでのテストも必要です。異なるサーバーには、クラスのロードなど、いくつかの特殊性がある可能性があります。ただし、組み込みコンテナーは、ロジックのテスト (単体テストと単体テストの統合) に役立つため、毎日の自動テストでは、これで十分かつ簡単になります。
埋め込みコンテナーは、完全なコンテナーよりも実行 (開始/停止) がはるかに高速です。これは開発者に確実に影響します。セットアップ/構成は、特に継続的な統合により、自動化が容易になります。一方、組み込みコンテナーでは一部のコア機能が無効になっているため、すべてをテストすることはできません。
http://www.jboss.org/arquillianを調査して、両方のオプションを使用することをお勧めします。サイトから:
Arquillian を使用すると、リモートまたは組み込みコンテナーでビジネス ロジックをテストできます。または、アーカイブをコンテナーにデプロイして、テストがリモート クライアントとして対話できるようにすることもできます。
最終的には、テストする EJB の種類によって異なります。特定の複雑なシナリオは、一部の外部サービスへのモックがないと、埋め込みコンテナーでは機能しません。私のプロジェクトでは、作成したカスタム モック コンテナ (超高速で使いやすい) を使用して EJBS をテストし、すべてがうまくいけば、Arquillian によく似たリモート コントロール API を使用して、実際の完全な JBoss でテストします。
それが役に立てば幸い。