なぜxUnitフレームワークではテストを並行して実行できないのですか?


15

今日のマシンで複数のコアを利用するために、テストを並行して実行できるxUnitフレームワークを知っていますか?

それらのどれもそれを行わない場合(または非常に少ない場合)、おそらく理由があります...テストは通常​​非常に速いので、人々は単にそれらを並列化する必要性を感じませんか?

(少なくとも一部の)テストを複数のスレッドに分散できないほど深いものはありますか?


ユニットテストは間違いなく遅いです。各テスト自体が高速であっても、文字通り何百万ものテストケースがあるので、それらは累積します。
Pacerier

回答:


6

NUnit 2.5には、テストを並行して実行できるpNUnitがバンドルされています。

このリリースには、分散並列テスト用の拡張NUnitランナーであるpNUnitが含まれています。pNUnitプログラムは、プラスチックSCMのテストに使用するためにCodice Softwareで開発され、NUnitに提供されています。pNUnitの使用に関する詳細については、pNUnitサイトを参照してください。

JUnit側には、aminoと同様にparallel-junitがあります。


他のフレームワークの唯一の理由は「まだ実装されていない」でしょうか?
ザビエルノード

1
@Xavierはい。それは公正な声明です。
アーロンマクアイバー

10

あなたの質問の2番目の部分に答えるために:複数のスレッドにテスト(少なくともいくつか)を配布することを妨げるより深い何かがありますか?

大量のコードは、シングルスレッドで実行する場合にのみ機能します。シングルスレッドで実行されることを前提にプログラムを作成する場合、誤ってリソースの競合とデッドロックを生成するのは簡単です。ほとんどのプログラムは実際にシングルスレッドで実行されるため、これは問題なく機能します。並列処理は、複数のコピーまたは異なるプログラムを同時に実行することで得られます(Webスクリプトの1つの一般的な例-多くのユーザーが1つのページにアクセスすると、そのページのスクリプトのコピーが大量に同時に実行されます)。

単純な「ファイルへのログ」クラスを想像してください。インスタンスを作成すると、書き込み用にファイルが開かれ、インスタンスを解放すると、ファイルが閉じられます。したがって、最初のテストはインスタンスを作成し、テストの実行を開始します。2番目のテストは、2番目のスレッドで同じことを行います。また、2番目のインスタンスはファイルへの書き込みアクセスを取得できないため、失敗します。ただし、一度に1つずつ実行すると、すべてのテストに合格します。

これらはすべてコーディングすることができ、簡単な例は微調整して動作させることができます。しかし、元のプログラムではおそらくそれを行う必要はありません。単体テストを実行できるようにスレッドセーフコードを記述する必要があることは、多くの人にとっては不合理です。したがって、マルチスレッドユニットテストはオプションとして追加する必要があります。


+1これは、実際に理由に答えるので、例外的な答えであるべきです。
オリバーワイラー

4

テストがデータベースのセットアップとクエリを行う必要がある場合、並行して実行されるテストごとに個別のデータベースがない限り、並行して実行されるテストは互いに干渉します。


テストプラットフォーム(xUnit)が気にするものではありません。それは実装の詳細です。
アーロンマクアイバー

また、単体テストフレームワークで記述されたすべてのテストが単体テストであるわけではありません。データベースにアクセスするものが実際には単体テストではなく、統合テストのようなものです。
c_maker

テストがデータベースに触れるからといって、それが統合テストであるとは限りません。C#で部分的に実行され、たとえばデータベースsprocで部分的に実行されるメソッドは、事前構成が予期されない限り(つまり、データスキーマは存在するがデータは存在しない)、概念的に単体テストです。このようなテストでは、個々の実行のデータが作成される場合がありますが、終了したら空白状態にリセットする必要があります。これはおそらく議論の余地のある意見ですが、このようなテストは、小さなコード単位をテストする明示的にゼロ構成、ゼロ展開テストであるため、統合テストとは見なされません。
トリインコ

2

JUnit自体はそれを許可しないかもしれませんが(私はその最新バージョンに精通していません)、MavenとそのSurefireプラグインには、テストを並行して実行するオプションがあります。私はまだ試していません。

このオプションを調査することを強く求められているわけではありません。テストは1,000件以上あり、それらは十分に高速に実行されます。ただし、一部のテストフィクスチャには暗黙的な依存関係があることがわかっています(過去に一部のテストが予期せずに中断したときにそのような依存関係が見つかったため)。問題が明確になるため、これで問題ないと言えます。しかし、我々はレガシーシステムを扱っており、扱うべきより多くの重要な問題があります-時間は(通常のように)乏しいリソースです。


0

マルチスレッドコーディングは簡単ではありません。自分が何をしているのかを知っている人が行ったとしても、タイミングに依存するバグが発生する可能性があります。それらは修正が困難です。マルチトレッドで発生する可能性のある数千のケースタイプのバグを処理したので、テストフレームワークにそれらを含めないことを希望します。私が手に入れた最初の修正は機能しているように見えましたが、さらなるテストの結果、数万のバグの1つに過ぎなかったことがわかりました。

マルチプロセッサPCの出現により、マルチプロセッサ上でマルチスレッドを実行する技術が向上しています。ただし、それらが広く使用されるまでには時間がかかります。

一部のテストスイートには、テストが単一のストリームで実行されるときに明示的に指定する必要のないテスト間に依存関係があります。ただし、マルチスチームエンジンでは、明示的に指定する必要があります。(このような依存関係が存在する場所は別の質問です。)

別の観点から見ると、いくつかのことは並行して実行する必要がないだけです。プロセスが十分に高速に実行される場合、マルチスレッドの実装以外のことに集中する方がよい場合があります。


0

MBUnitは、いくつかのアセンブリレベルの属性を指定するだけで、テストを並行して実行できます。

[assembly: DegreeOfParallelism(6)]
[assembly: Parallelizable(TestScope.All)]

私は、このプロジェクトを使用して、しばらくの間、セレンテストを並行して非常にうまく実行しています。残念ながら、プロジェクトはもうあまり生きていません。

xUnit 2.0は、並列ユニットテストもサポートする必要がありますが、まだ試していません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.