Hudson を使用して、非常に大きな重要な製品のテストを自動化しています。マシンごとに一度に 1 つだけ実行する必要がある Excel テストを除いて、理論的にサポートされる限り多くの同時ビルドをテスト ホストで実行できるようにしたいと考えています。Excel 以外のテストはいくつでも同時に実行できますが、マシンごとに実行できる Excel テストは一度に 1 つまでです。
バックグラウンド：
私のテストのほとんどは、通常の単体テストです。これは、並列で簡単に実行できるようなものです。残念ながら、私の単体テスト計画の実質的で時間のかかる部分は、Excel で実装されたテストで構成されています。
Excel でテストを実装するのはおかしいと思うかもしれませんが、実際には重要な理由があります。ほとんどのユーザーは Excel を介してシステムにアクセスしています。Excel には独自の風変わりなデータ処理方法があるため、私たちの機能が Excel ユーザーに対して機能することを保証する唯一の方法は、文字通りアプリケーション Excel の正規テストを実装することです。
Excel テストのグループを簡単に起動できるテスト ランナー ツールを作成しました。各テストは 1 つの .xls ファイルです。各グループは、Excel ファイルでいっぱいのフォルダーです。エンドツーエンドのテストのために実行する必要がある約 30 のグループがあります。私のツールは、各テストの結果を Hudson が理解できる JUnit スタイルの XML に変換します。テストでは、pywin32com ライブラリを使用して Excel を自動化します。単独で実行すると、信頼性が高くなります。
テストの実行専用のコンピューターのグループがあります。各マシンはクアッドコアであり、理論的には一度にかなり多くのものを実行できます。残念ながら、COM を使用して一度に 1 台のマシンで複数の Excel を安全に制御することはできないことがわかりました。
つまり、COM 経由で Excel と通信しようとする 2 番目のビルドが開始されると、既に実行されているビルドに干渉し、両方のテストが失敗する可能性があります。
マシンが許可する限り他の非 Excel プロセスを実行できますが、Hudson が同時に 1 台のマシンで Excel を必要とする複数のプロセスを起動しようとしないようにする方法を見つける必要があります。