1

これは楽しいものです。

サーブレット アクセスを使用して tomcat で実行されるアプリケーションがあります。基礎となる実装では、ThreadPoolExecutorを使用してタスクを細分化します。この時点では、電子メール ディストリビューターのみです。私は JUnit テストを追加しており、cobertura によって報告されたコード カバレッジを、ほぼ許容できるレベルまで徐々に上げています。JUnit テストの背景:

  1. @ BeforeClassでは、テスト環境で有効な DB 接続ルックアップのコンテキストを設定しています。
  2. サーブレット テストでは、HttpUnitを使用してInvocationContextを取得し、次にサーブレットのインスタンスを取得しています。
  3. 次に、すべての作業を行うサーブレットのプライマリ メソッドを呼び出し、最終的に適切な分散メソッドのスレッド マネージャーを呼び出し、前に定義した ThreadPool を使用します。
  4. この問題は、生成されたスレッドで発生します。サーブレットからの DB アクセスは、 @ BeforeClassで作成されたコンテキスト設定を使用して問題なく機能します。スレッドはそのコンテキストにアクセスできず、DB 接続情報を取得できず、スレッド コードでエラーが発生します。

要するに、DB アクセスが必要なスレッド コードをテストする方法を知っている人はいますか? または、DB アクセスを必要とするマルチスレッド アプリケーションで機能する、まったく新しいユニット テストの方法ですらあります。

任意の追加の詳細をポイントに提供できます。実際のコードを提供する必要がないように、十分な情報を提供したことを願っています。

4

1 に答える 1

0

スレッドプールに送信されたタスクを拡張し、DB コンテキストを拡張タスクに追加し、作成した新しいテストよりもコンテキストを取得してデータベースへのアクセスに使用することをお勧めします。あなたの質問に答えてくれることを願っています。そうでない場合は、コード例を追加してテストできるようにしてください。

于 2013-02-06T11:12:41.617 に答える