.NET の単体テストを並列実行する - テストフレームワークごとの違い

C# など .NET プログラム開発における、単体テストプロジェクトの実装・実行の話題。

自分が抱えているとある案件の単体テストプロジェクトにおいて、単体テストプロジェクト内の複数のテスト (テストメソッドや、テストパラメータ) を、1つずつ順番に実行するのではなく、並列実行したい状況が発生した。

そこで、単体テストフレームワークごとに、テストの並列実行のやり方についてどのような違いがあるか、確認してみることにした。

なお、自分が扱える単体テストフレームワークは以下の3つ。

• xUnit.net
• NUnit
• MSTest

上記 3 つの単体テストフレームワークごとの、テストの並列実行の違いを、Windows OS 上の Visual Studio 2019 のテストエクスプローラからの実行で調べてみた。

調査用に作成した C# による単体テストフレームワークごとプロジェクト一式は、下記 GitHub リポジトリに公開してある。

そして下記の表は、調べてみた結果を雑にまとめてみたもの。
★ 印はそれが既定の振る舞いであること、○ 印はその並列実行をサポートしていることを示している。

	xUnit.net	MSTest	NUnit
並列実行なし	○	★	★
クラススコープでの並列実行	★	○	○
メソッドスコープでの並列実行		○	○
パラメータスコープでの並列実行			○

以下、上記表の並列実行のスコープについて、もう少し説明してみる。

並列実行なし

これは単純に、すべてのテストメソッド、テストパラメータが、順番にひとつずつ実行される形態である。

MSTest および NUnit では、特になにも指定しない場合の並列実行に関する動作はこれである。

クラススコープでの並列実行

異なるテストクラスのテストメソッドが並列実行される形態である。

すなわち、

•   テストクラス A にテストメソッド X があり、
  
•   テストクラス B にテストメソッド Z があるとき、
  
•   別々のクラスにあるテストメソッド X と Z は並列実行される
  

というものだ。

ただし、テストクラス A 内のテストメソッド X と Y は、(これらのテストメソッドは同じクラス内なので) 並列実行されない。

xUnit.net では、このクラススコープの並列実行が既定の動作であるようだ。

および、MSTest と NUnit でも、追加の指定が必要であるが、クラススコープでの並列実行が可能である。

メソッドスコープでの並列実行

異なるテストクラスももちろん、同一テストクラス内のテストメソッドも並列実行される形態である。

すなわち、

• テストクラス A にテストメソッド X と Y があり、
  
• テストクラス B にテストメソッド Z があるとき、
  
• これらすべてのテストメソッド X, Y, Z は並列実行される

というものだ。

xUnit.net ではメソッドスコープでの並列実行はサポートされていないらしい。

いっぽう、MSTest と NUnit では、追加の指定で、メソッドスコープでの並列実行が可能だ。

パラメータスコープでの並列実行

今回評価したいずれの単体テストフレームワークにおいても、「テストメソッドに引数を設け、引数に渡す値 (テストパラメータ) を変えながらテストメソッドを実行する」という、いわゆる "データ駆動テスト" に対応している。

パラメータスコープでの並列実行は、このデータ駆動テストにおいて、引数に渡す値 (テストパラメータ) 違いのテスト実行が並列実行されるというものだ。

このスコープでの並列実行は、NUnit のみが対応している模様。

フレームワーク別にもう少し補足

xUnit.net

並列実行の "スコープ" はクラスレベルまでしかできないっぽい。

その他の並列実行に関する構成は、[Collection] 属性をテストクラスに付与して "テストコレクション" という並列実行の "単位" を個別にくくりだしたり、アセンブリ属性 [CollectionBehavior] にて並列実行のスレッド数を指定したりなどができるようだ。

詳細はいずれも公式ドキュメント (下記) に記載がある。

NUnit

並列実行のスコープを、テストケースやテストメソッドに [Parallelizable] 属性を付記することで制御できる。

ただ、[Parallelizable] 属性の指定を細やかに組み合わせようとすると、どれとどれが並列実行されるのか事前の予想がしにくかった。 (慣れの問題?)

MSTest

並列実行のスコープを アセンブリ属性 [Parallelizable] で指定できる。

指定はアセンブリ単位だが、[DoNotParallelize] 属性をテストクラスまたはテストメソッドに付けることで、テストクラスやテストメソッドごとに個別に並列実行しない指定が可能だ。

Visual Studio の [テストを並列で実行する] の効果は?

ところで、Visual Studio IDE のテストエクスプローラの設定には、[テストを並列で実行する] というチェック項目がある (下図)。

しかしながら、前述のテストフレームワークごとの並列実行に関する振る舞いには、このチェック項目の設定は何ら影響しない様子である。

ではこのチェック項目はどういう効能があるかというと、現在開いているソリューションに、複数のテストプロジェクトが含まれていた場合に、それらテストプロジェクトのテスト実行を並列実行するかどうかを制御している模様だ。

言うなれば、"アセンブリ" スコープでの並列実行を選択できる項目ということだ。

まとめ

以上、ざざっとテストフレームワークごとの並列実行の指定の方法やその性質について調べてみた。

自分の確認不足や誤認などで、本投稿の内容には誤りもあるかもしれないので、その点は注意していただきたい。

なお、テストは何でもかんでも並列実行すればよいというものではないだろう。

いくらマルチコアが一般的な今日現在とはいえ、テスト対象のコードが搭載コアをフル活用するような CPU 計算中心なコードであった場合などは、かえって並列実行するとトータルのテスト実行時間は長くなってしまう可能性もある。

もしかしたら、CPU の温度が上がりすぎてサーマルスロットリングが発動し、かえって遅くなった、なんてこともあるかもしれない。

他方、I/O 処理待ちなどの非同期処理を含むようなケースでは (※単体テストでそのようなコードを対象としたテストは希だと思うが)、テストを並列実行することで、トータルのテスト実行時間を短縮化できる可能性が高くなる。

自分のケースだが、データ駆動テストのテストケースが大量な xUnit.net で実装したテストプロジェクトがあって、これのトータルのテスト実行時間が 125秒 かかっていた。
これを  (xUnitではパラメータ違いのテストを並列実行できないっぽかったので) NUnit に載せ替えて並列実行化したところ、73秒にまで短縮できた。

上記はテストの並列実行によってトータルのテスト実行時間を短縮できた成功例ではあるが、当然、すべての単体テストプロジェクトでこのとおりうまくいくとは限らない。
また、本稿では端折ったが、並列実行できるようなテストコードを実装する必要も出てくる。
テストの並列実行は、よくよく考えて、そして実行結果を測定しながら進めるのがよろしかろう。