Nunit: フィクスチャ内でテストメソッドを並行して実行する

作成日 2014年08月05日  ·  76コメント  ·  ソース: nunit/nunit

現在、フィクスチャレベルでの並列実行のみを実装しています。 パラメータ化されたメソッドの個々のテストケースだけでなく、フィクスチャの個々のメソッドも並行して実行できる必要があります。

フィクスチャまたはメソッドの並列処理の正確なレベルを指定できる必要があります。

この問題は以前は#66の一部でした

done hardfix feature high

最も参考になるコメント

私は未来を予測するふりをすることができましたが、それは9月まであなたを満足させるでしょう。 :-)

機能を「スケジュール」する方法を説明して答えさせてください。

現在、(年初から)四半期に1回リリースされるアプローチを試みています。 リリースが上手になると、ペースが上がる可能性があります。 最終的には、継続的な展開が可能になる可能性があります。

ボランティアのオープンソースプロジェクトでは、1か月に利用できる一定の労力はありません。 「昨日の天気」のアプローチを使用することはできますが、人々がNUnitに費やす必要のある時間と、ボランティアをする人々の数はかなり変動することがわかりました。

妥協案として、リリースの鍵となる少数の問題を選択し、事前にマイルストーンに追加します。 私の好みは、私たちがやりたいと思うことの約25%以下を追加することです。 リリースの問題の大部分は、それらが完了した後、またはせいぜい誰かがそれらに取り組むことを約束したときにのみ、そのマイルストーンに追加されます。 3.5マイルストーンでは、誰かが割り当てられていないと、一般的に未解決の問題は見つかりませんが、何かが他の作業をブロックしているように見える場合は、時々それを行います。

したがって、私たちが行うことの良い面は、リリースが時間どおりに行われることを事実上保証できることです。 マイナス面は、何が含まれるかがわからないことです。 :-(

この特定の問題については...開発者にそれが重要であることを伝えるために、私はそれに高い優先順位を与えました。 誰かが自由にそれに取り組むことができ、この範囲と難しさのプロジェクトのための十分な背景を持っている必要があります。 適切なバックグラウンドを持つ誰かが今後数週間でこれを取り上げれば、リリースまでにそれを行うことができると思います。 ガイドラインとしては、他のことにも取り組んでいるうちに、これをやり遂げるのに約1ヶ月かかると思います。

申し訳ありませんが、これ以上決定的な答えはありませんが、そのような答えは必然的に嘘になります!

全てのコメント76件

更新:このコメントと次のコメントはどちらも、明らかに自分のコメントを削除した個人への返信でした。 私は答えを残しています。

まあそれは仕様にあり、3.0以降の実装が予定されています。 もしそれがとても簡単だったら、私たちはおそらくそれをしたでしょう。 mbunitとの接続がわからない。 彼らがそれを持っていたという事実は私たちを助けません。

これは少し面倒になっています。 すでに述べたが明らかに見逃したいくつかのポイント...

  1. あなたが求めているものを実行する計画があります。
  2. 私たちはチームとして、ある時点でそれをスケジュールすることにしました。
  3. スケジュールされる時期は、主に、他の機能と比較した機能の価値の評価と関係があります。
  4. NUnitチームには、この機能を実装できる人が何人かいます。
  5. 彼らは、優先順位に応じて、頭からそれを実装することができ、どこからでもそれをコピーする必要はありません。

「リバースエンジニアリング」についてのあなたの話は非常に気がかりです。 オープンソースは、著作権が尊重される状況でのみ可能です。 したがって、mbunitのライセンス条項を無視する可能性があることを示唆している場合は、ベースから大きく外れています。

私はMbUnitに多くのパッチを提供し、それを何年も使用していましたが、
決して主要な貢献者ではありません。 私は自分のステータスが誤って伝えられることを望まないでしょう:)

リバースエンジニアリングに関しては、ここでは実際には何の用途もありません。 NUnitは機能します
MbUnitとはまったく異なります。 やがてこの問題に到達しますが、
しかし、他の同様の問題が変わる可能性があるため、慎重にアプローチしています
これを実装するために必要な方法、あるいは競合さえも。
2015年4月19日午前2時45分、「CharliePoole」 [email protected]は次のように書いています。

これは少し面倒になっています。 すでに述べたいくつかのポイントが
どうやら逃した...

1.1。

あなたが求めているものを実行する計画があります。
2.2。

私たちはチームとして、ある時点でそれをスケジュールすることにしました。
3.3。

それがスケジュールされるときは、主に私たちの評価と関係があります
他の機能と比較した機能の価値。
4.4。

NUnitチームには、
特徴。
5.5。

彼らは、優先順位に応じて、
彼らの頭とどこからでもそれをコピーする必要はありません。

「リバースエンジニアリング」についてのあなたの話は非常に気がかりです。 オープンソースは
著作権が尊重される状況でのみ可能です。 だからあなたが
mbunitのライセンス条項を無視する可能性があることを示唆しているので、あなたはかなり離れています
ベース。


このメールに直接返信するか、GitHubで表示してください
https://github.com/nunit/nunit/issues/164#issuecomment-94244650

私よりもはるかに巧妙なコメント!

並列実行の世界における現在の優先事項は次のとおりです。

  1. 並列プロセス実行
  2. 除外グループ
  3. 並列メソッド(1つのフィクスチャ内)の実行。

これは、ユーザーにとって最も有用な順序を表しているようです。

また、3.0以降として何かをマークすることは、3.0の一部にした場合よりも後で機能が提供されることを必ずしも意味しないことにも言及します。 むしろ、3.0がより早い時点で登場することを意味するかもしれません。

これを行うときは、セットアップコマンドとティアダウンコマンドの処理方法を決定する必要があります。 最も簡単なオプションは、データの競合が発生しないように、各テストのテストクラスを作成することです。

とにかく、ある時点でそのオプションを作成することをお勧めしますが、それが実行オプションなのか、フィクスチャごとの(属性付き)オプションなのか、あるいはその両方なのかはわかりません。

やあ!
この機能を次のバージョンのNUnitに追加すると、NUnitへの切り替えを妨げる唯一の機能になるので便利です。 この機能はまだ3.4で計画されていますか?

@julianhaslinger NUnit 3.4は

参考までに、この問題は3.4ではなくバックログマイルストーン(または疑似マイルストーン)にあります。これは、番号が付けられた各マイルストーンに少数の重要な定義の問題のみを事前に追加するという慣行に従っているためです。

次のマイルストーンである3.6は、あと3か月で低下する予定ですが、これはおそらくあなたを落胆させるように聞こえます。 :-(ただし、この問題がマスターにマージされている場合は、MyGetフィードから以前のドロップを取得できます。

@julianhaslingerこれは3.4には含まれず、おそらく1週間

余談ですが、並列メソッド実行をサポートするテストフレームワークを使用していますか? XUnitでは、クラスレベルまで並行してテストを実行することしかできないと思いました。 私は間違っていますか? XUnitはあまり使用していません:smile:

@CharliePoole答えてくれてありがとう! わかりました、しかし、これは少しがっかりするように聞こえます。 ただし、次のリリース(または以前のドロップ)を待ちます。 次のバージョン(3.6)でこの機能を(まだ)検討してください。

@rprouse現在MbUnit / Gallioを使用しています。 プロジェクトはほとんど終了しました。次に、NUnitに切り替えます。

@julianhaslingerそれはあなたのための実行

@CharliePoole正確に言えば、実際の問題はテストケースの実行時間です。 自動化/回帰テスト(Selenium / WebDriverを含む)にNUnitを使用したいと考えています。一部のテストクラスには、200以上のテストケースがあるため、現在、NUnitを使用してテストスイート全体を実行するのは非常に困難です。

比較(回帰テストのより小さなテストセット内)では、可能なNUnitソリューションが約1.5時間で実行されるのに対し、現在のMBunitソリューションは0.5時間で実行されることが示されています(同じテストセット)。

ただし、 @ CharliePooleは、大きなテストクラスを小さなテストクラスに分割することで実行時間を短縮できる可能性があることを認識していますが、これはテストクラス階層の最初のアイデアを何らかの形で損なうことになります。

@ julianhaslinger-確認のために、実行時間はCPUにバインドされており、メモリにバインドされていませんか?

最初にNUnit3に切り替えようとしたときに、同じ問題が発生しました。実行時間が大幅に長くなりました。 これは、NUnitが使用可能なメモリを使い果たしたことが原因でしたが、現在のバージョンには、テストの実行が完了するまですべてのテストオブジェクトを保持するという問題があります。 現在、パッチを適用したバージョンを社内で実行しています。3.4のPRを取得したかったのですが、現時点で時間がないかどうかはわかりません。 :-(

そうでない場合はお詫びしますが、Seleniumはメモリのかなりの部分を使用できるため、言及する価値があると考えました。 :-)

@ChrisMaddock入力ありがとうございます! :+1:すぐに確認しますので、折り返しご連絡いたします。

@ ChrisMaddock3.4でメモリが修正されるのを楽しみにしています。 PRを作成したい場合、まだ本番環境の準備ができていない場合は、クリーンアップをお手伝いします:+1:

@ rprouse -PR#1367のこの最初のコミットhttps://github.com/nunit/nunit/pull/1367/commits/5f98ae51025f7af8244abd4367d1f47260874dfcは、パッチが適用されたv3.0.1で適切に解放されます。

PRで、マージ前にOneTimeTearDownに移動されたことがわかります-その移動によってv3.2.1で機能しなくなったのか、それとも別の変更が機能して再導入されたのかはまだわかりません。保持-私は引っ越した後に再テストしなかったかもしれません。

それを再テストして明日投げます。コアリリースに戻るのも素晴らしいことです。 :-)

@ChrisMaddock回帰テストの実行中のメモリ消費量を調べたところ、テスト実行の実行がメモリに依存していないことがわかりました。 各クラス内の個々のメソッドの並列実行を処理できるバージョンのNUnitを本当に待つ必要があると思います。

@julianhaslingerが言ったことに加えて、SeleniumテストでNUnitを使用するときにまったく同じ問題が発生しました。 今のところ並列テストを実行できるように、渡されたアセンブリから取得した単一のテストに対してnunit-console.exeの個々のインスタンスを実行するカスタムラッパーを作成する必要がありました。 ただし、これは、単一の.xml出力ではなく多くの.xml出力ファイル(テスト実行ごとに1つ)が生成されるため、理想的ではありません。また、_OneTimeSetUp_メソッドとティアダウンメソッドを使用できず、代わりに外部セマフォに依存する必要があることを意味します。一度だけ実行したい実行フローを制御するための環境変数。 私は長い間(数年)NUnitで並列実行するという約束を守ってきましたが、この機能が3.0でどのように展開されたかに非常に失望しました(部分的にしかサポートされておらず、問題とリリースノートを実際に掘り下げる必要があります。すべてが実際にサポートされているわけではないことを発見してください)。 これを自分で進めるために何が必要かを調査することさえしましたが、残念ながら、NUnitの設計は、テストメソッドレベルでの並列実行の実装に反しているようです。実際にどのようにしたいかわかりません。スレッドセーフでないコードの可能性を処理するため(つまり、すべてのテストメソッドがスレッドセーフな方法で外部を適切に参照するようにNUnitを並行して使用する人に任せるか、NUnit自体が何らかの方法で独自のドメインで各メソッドの実行を処理する必要がありますまだ1回限りのセットアップとティアダウンタイプのメソッドを1回だけ実行しようとしています)、すでに回避策が用意されているため、この機能を自分で実装する時間を正当化できませんでした(これは、以前にやけどを負ったことがあるため、おそらく最善です) GitHubのチームと協力して、並列実行の実装を支援します)。 とにかく...とりとめのない申し訳ありません... C#コードのユニットテストの優先順位はおそらくメソッドレベルの並列処理にそれほど依存していないことを理解していますが、SeleniumベースのテストにNUnitを使用している私たちにとってはそれを知っておいてくださいそれは大きな改善になるでしょう。 前もって感謝します! :笑顔:

コメントしてくれてありがとう。 私はここで少し自分で歩き回ると思います...

人々が何を必要とし、なぜそれを必要とするのかを理解するのに役立ちます。 私自身はWeb開発者ではないので、Seleniumユーザーの話を聞いて、彼らが望んでいることに集中しようとしました。 それは、テストケース間の順序付けを伴う並列フィクスチャであるように見えました。 人によって欲しがるのは違うと思いますが、どちらのグループも「Seleniumユーザーが必要としているもの」を表現していると少し混乱します。 事前定義された順序でメソッドを実行したい人とは対照的に、どのような種類のWebテストでメソッドレベルの並列性が必要になるかについて概説していただけますか? 推測できると思いますが、むしろユーザーから入手したいです。

回避策について...個別のテストアセンブリの使用を検討しましたか? NUnitは、それぞれを別々のプロセスで並行して実行できることをうれしく思います。 もちろん、それはファイルのようなものへのアクセスを同期する必要性を排除するものではありません。

スレッドセーフに関して-私たちは、並列実装がスレッドセーフの責任を取ることを計画していませんでした。 私が保証することを期待していた唯一のことは、メソッドがすでにスレッドセーフである場合、NUnitがスレッドセーフの問題を引き起こさないということです。 それ自体が重要であることが判明しました。

返信ありがとうございます。 私はあなたのコメントを完全に理解しています
フィクスチャでのテスト実行の順序付けとテストの個別の分割
アセンブリ。

私はすでにNUnitユーザーであり、何年も前からJUnitを使用しています(その前はJUnit)
したがって、フィクスチャ内のテストの順序に依存するという考えは、
私のテストデザインでの考慮事項。 各テストは完全にカプセル化されようとします
サイト内のアクションまたは一連のアクション。
実行。 私がテストしているサイトのデザインはまた、多くのテストを意味します
実行には最大20分かかる場合があります(この時間の多くは待機に費やされます
サイトで起こることのために)そしてテストの種類はカバーしています
複数の同様のシナリオなので、基本テストクラスを使用してコードを削減します
共通の基本クラスを使用することにより、複製と保守性の向上
メソッド。 テストは、開発者に基づいて個別のプロジェクトに編成されます
その領域のチーム所有権(したがって、個別のアセンブリを使用しますが、
アセンブリごとに多くのテストがあり、私のテストラッパーはの実行を処理します
以前に作成されたように、すべてのテストがすべてのアセンブリで並行して渡されました
NUnit 3の最初の公式リリースであり、すべてのテストで
十分なスレッドが与えられた場合に同時に実行される可能性
利用可能)。

基本的に、1つのアセンブリに10のテストがあり、
さらに100回のテストがありますが、10個のアセンブリには10分かかるテストがあります
それぞれ100のアセンブリには、それぞれ1分かかるテストがあります。 もし私が
110の並列スレッドを実行できるマシンがあります(実際には
インフラストラクチャ設計の一部)その後、テストが終了することを期待します
100分ではなく10分で。

うまくいけば、これが説明に役立つでしょう...物事がまだ完全に明確でない場合は申し訳ありませんが、
しかし、全体的なポイントは、メソッドレベルの並列処理は私が持っているものであるということです
他のテストライブラリ(たとえば、rubyのprspec)で欠落しているのが見られる
それを追加することによって得られるべきパフォーマンスの改善の分析を行うi
それは大きな前向きな変化である可能性があることがわかりました。 例として、以下を参照してください。
https://github.com/bicarbon8/rspec-parallel/wiki/Examples
2016年7月1日00:45、「CharliePoole」 [email protected]は次のように書いています。

コメントしてくれてありがとう。 私はここで少し自分で歩き回ると思います...

人々が何を必要とし、なぜそれを必要とするのかを理解するのに役立ちます。 ではない
私自身、Web開発者は、Seleniumユーザーの話を聞いて、何に焦点を合わせようとしました。
彼らが望んでいました。 どうやら注文のある並列フィクスチャだったようです
テストケースの中で。 さまざまな人が欲しがるだろうと私は完全に理解しています
異なるものですが、両方のグループが表現しているように自分自身を提示するとき
「Seleniumユーザーが必要とするもの」は少し混乱します。 概要を教えていただけますか
どのような種類のWebテストで、メソッドレベルの並列処理が必要になる可能性がありますか
事前定義された順序でメソッドを実行したい人はいますか? 私はできると思います
推測しますが、私はむしろユーザーからそれを持っていると思います。

回避策について...別のテストを使用することを検討しましたか
アセンブリ? NUnitは、それぞれを別々に並行して実行できることをうれしく思います。
処理する。 もちろん、それはアクセスを同期する必要性を排除するものではありません
ファイルのようなもの。

スレッドセーフに関して-並列実装を計画したことはありません
スレッドセーフの責任を取る。 私が期待していた唯一のこと
保証は、NUnitがスレッドセーフの問題を_作成_しないことです。
メソッドはすでにスレッドセーフです。 それ自体が重要であることが判明しました。


あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/nunit/nunit/issues/164#issuecomment -229819324、またはミュート
スレッド
https://github.com/notifications/unsubscribe/ACNsyoczCUV9L7kbF2SHB7lLsyBKlrv9ks5qRFUJgaJpZM4CUZ8r

情報をありがとう...さまざまな視点を見るのは役に立ちます。

私の5セント。

私たちのプロジェクトでは、最大25のテストアセンブリがあり、アセンブリごとおよびフィクスチャごとにテストを並行してテスト実行すると、実行時間が大幅に短縮されます。 フィクスチャ内でテストを並行して実行すると、フィクスチャがさらに改善されます。 今では、実行を高速化するために、最も時間のかかるフィクスチャをいくつかのフィクスチャに分割することもできますが、nunitがフィクスチャテストを並行して実行する方がはるかに優れています。

私がnunitで本当に見たいのは、テストケースレベルでのテストの並列化です。このようなテストをフィクスチャに分割することは必ずしも便利ではなく、コードの重複につながるためです。 最大で数千のテストケース(それぞれのケースの実行は高速ですが、合計で数分かかります)または数十のケース(ただし、それぞれのケースは遅い)をとる可能性のあるいくつかのテストがあり、今のところ、そのようなテストは我ら。

入力をありがとう...これは、いくつかのテストが互いに並行して実行されないようにするという競合するが補完的な問題とともに、次のリリースで対処する予定の領域です!

私の以前の質問は、特にWebアプリケーションを駆動するときに、人々がどのようにテストを書いているかについてでした。 一部の人々は、各メソッドをシーケンスされたステップにし、フィクスチャがそのような一連のステップを表すことを望んでいると主張します。 もちろん、これは定義上非並列です。 他の人々は、テストを順序付けせずに非常に類似したテストを書いているようです。 私の推測では、後者のグループは、それぞれに一連のアクションとアサーションを含む、より大きなテストメソッドを作成します。

@CharliePoole素晴らしいニュースです! どうもありがとう!

私の意見では、テストケースは分離されるべきであり、他のテストケースや実行順序に依存しないようにする必要があります。 それでもシングルスレッドでいくつかのテストを実行したい場合は、[Parallelizable(ParallelScope.None)]やOrderAttributeを使用できます。

実装されているこの問題により、ローカルのWebドライバーグリッドやBrowserStackやSauceLabsなどのSaasプロバイダーと比較して、テストスイートをより高速に実行できるようになります。 現在、テストクラスのテストメソッドの量を、使用可能なWebドライバーノードまたはブラウザーセッションの数に制限しようとしているため、グリッドは完全に使用されています。 それ以外の場合、テストに8つのテストメソッドがあり、グリッドに8つのブラウザセッションが利用できる場合、クラスのすべてのテストメソッドが一度に1つずつ実行されるため、1つだけが使用されます。

@pablomxnl絶対に同意します。 コーチまたはプロジェクトリーダーとして、私は常にそのアイデアを非常に強く推し進めてきました。 しかし、私はここではそれらの帽子のどちらも着ていません。 私は物事を求めるユーザーがいるソフトウェアプロバイダーです。 彼らが本当にひどいものを求めたら、私はただノーと言います。 しかし、ある状況では合理的であるが、他の状況では(ほとんどではない)ではないことを彼らが求めている場合、私はそれを考慮します。

Webサイトの場合、ほとんどの場合、単体テストについて話しているわけではありません。 高レベルの機能テストでは、多くの場合、シーケンス処理が必要です。 テストの一連のステップを介して実行されるか、一連のメソッドを介して実行されるかは、実装の詳細であり、ユーザーの利便性の問題です。 個人的には、[StepFixture]クラス内にある[Step]と呼ばれるもの、または同様の名前が必要だと思います。そうすれば、これらすべての順序付け/順序付けを単体テストから取り除くことができます。 たぶん、ウェブが死ぬ前にそれをする時間があるでしょう。 :-)

とにかく、人々が実際にあなたのソフトウェアをどのように使用しているかを学ぶことは常に興味深いことです。

@CharliePoole 、これを

私は未来を予測するふりをすることができましたが、それは9月まであなたを満足させるでしょう。 :-)

機能を「スケジュール」する方法を説明して答えさせてください。

現在、(年初から)四半期に1回リリースされるアプローチを試みています。 リリースが上手になると、ペースが上がる可能性があります。 最終的には、継続的な展開が可能になる可能性があります。

ボランティアのオープンソースプロジェクトでは、1か月に利用できる一定の労力はありません。 「昨日の天気」のアプローチを使用することはできますが、人々がNUnitに費やす必要のある時間と、ボランティアをする人々の数はかなり変動することがわかりました。

妥協案として、リリースの鍵となる少数の問題を選択し、事前にマイルストーンに追加します。 私の好みは、私たちがやりたいと思うことの約25%以下を追加することです。 リリースの問題の大部分は、それらが完了した後、またはせいぜい誰かがそれらに取り組むことを約束したときにのみ、そのマイルストーンに追加されます。 3.5マイルストーンでは、誰かが割り当てられていないと、一般的に未解決の問題は見つかりませんが、何かが他の作業をブロックしているように見える場合は、時々それを行います。

したがって、私たちが行うことの良い面は、リリースが時間どおりに行われることを事実上保証できることです。 マイナス面は、何が含まれるかがわからないことです。 :-(

この特定の問題については...開発者にそれが重要であることを伝えるために、私はそれに高い優先順位を与えました。 誰かが自由にそれに取り組むことができ、この範囲と難しさのプロジェクトのための十分な背景を持っている必要があります。 適切なバックグラウンドを持つ誰かが今後数週間でこれを取り上げれば、リリースまでにそれを行うことができると思います。 ガイドラインとしては、他のことにも取り組んでいるうちに、これをやり遂げるのに約1ヶ月かかると思います。

申し訳ありませんが、これ以上決定的な答えはありませんが、そのような答えは必然的に嘘になります!

@CharliePooleこの機能を考慮したアップデートはありますか?

@tomersssはまだ作業を開始しておらず、3.5は数週間以内にリリースされることを期待しているため、次のリリースには含まれない可能性があります。 この機能がすぐに追加されることを望んでいますが、今週はリポジトリとコードベースの再編成にかなり忙しくしています。 しかし、それは優先度が高いとマークされているので、私たちのレーダーにあります。

@CharliePooleこの問題に対する更新はありますか?

@KPKAまだ作業を開始していないため、更新はありません。 ZenHubがインストールされているユーザーの場合、作業を開始すると、この問題がBacklogからToDoに移動し、次にInProgressに移動することがわかります。

Zenhubを使用していない場合は、誰が問題に割り当てられているかを確認することで、誰かがいつそれを手に取ったかを知ることができます。

@CharliePoole @rprouse

やあ!

この問題に関するニュースはありますか?
次のリリースになるのか、それとも今後のマイルストーンの1つで計画されるのか。

現時点では、これがNUnitへの切り替えを妨げている唯一の問題です。
多くの人が影響を受けているので、近い将来、誰かがこれに取り組むことを自白できれば親切だと思います。

すぐにお返事をお待ちしております

@GitSIPAテストメソッドを並行して実行できるようにするために使用しているテストフレームワークは何ですか?

あなたの質問に答えるために、誰もこの問題に取り組み始めていないので、ETAはありませんが、次に何に取り組むかを決定する際に、あなたの投票を考慮に入れます。

+ 1、@ GitSIPAに同意します。 これは本当に重要な機能です

@GitSIPA +1
@rprouse mbunitを使用していますが、このフレームワークは現在サポートされていません。 そして、mbunitにはいくつかの問題があります。

@rprouse現在MbUnitも使用していますが、新しいVisual Studioバージョンはサポートされていないため、NUnitへの切り替えを検討しました。

問題#1921で、 @ jnm2は、「私たちとパラメーター化されたテストケースを並行して実行することの間に何がありますか?貢献できますか?」と尋ねました。

最初の2番目の質問:確かに! よろしくお願いします。

そして最初の質問に:

  1. 現在、テストに1対1でマップする「WorkItems」を実行します。 準備段階として、フィクスチャのOneTimeSetUpとOneTimeTearDownを別々のWorkItemとして扱う必要があると思います。 第1096号はこれを扱っています。

  2. WorkItemを他のWorkItemに依存させる方法が必要です。これにより、WorkItemは、アイテムに依存するすべてのアイテムが完了したときにのみ実行されるようにスケジュールされます。 現在、CountDownを使用して非常に単純な方法でこれを行っていますが、より一般的なものが必要です。 もちろん、これを最初に使用するのは、OneTimeTearDownをすべてのテストの完了に依存させることです。 後でテスト間の依存関係を実装するときに、他の用途があります。 私はこれを保留中の作業項目のキューとして描いていますが、それを実装する他の方法があるかもしれません。

  3. これらの2つのことが邪魔にならないので、主要な問題自体に取り組み始めることができます。フィクスチャのOneTimeSetUpを実行したのと同じスレッドでテストを実行するのではなく、実行するようにテストをスケジュールします。

これに取り組みたい場合は、NUnitが実際に実行のためにテストをディスパッチする方法の内部のいくつかに非常に精通している必要があります。 私はあなたがそれをするのを手伝ってうれしいです。

これまでにどのような計画が立てられましたか?
私のニーズは、CPUを飽和させるのに十分なTestCaseSourceケースを並行して実行することです。 セットアップ、分解、注文の要件はありません。 ただし、他の人はそれらを考慮に入れる必要があります。

TestCaseSourceの実行は並列化されると予想されるため、異なるTestCaseSourcesを使用する同じフィクスチャ内の2つのメソッドは、列挙を並列に実行します。 また、2つのメソッドが同じTestCaseSourceを使用した場合、それが1回だけ実行されたとしたら、それは素晴らしいことだと思います。これについて考えてみてください。

編集:競合状態のコメント。 すでに良いスタートを切っています! 😆

最近よく言わなければならない話を繰り返します。 :笑顔:

NUnitは、最初にテストをロードし(別名、検出、探索)、次にランナーのタイプに応じて1回以上実行します。

TestCaseSourceは、テストの実行ではなく、テストのロードに使用されます。テストと同じクラスにある場合でも、テストの一部とは見なされません。

IOW、テストケースはテストケースソースを「使用」せず、NUnitはソースを使用してテストケースを作成します。 もちろん、作成されるまで何もできません。 わかる?

たまたま、ソースからのテストの作成は順番に行われます。 それを問題にするソースで実行されているコードがある場合、私の最初の推測は、テストケースソースでやりすぎだと思います。 たとえば、テストケースソースにクラスのインスタンスを作成するのではなく、それらを作成するために使用されるパラメーターを格納する必要があります。 残念ながら、これは本全体の章になる可能性があります。 :笑顔:

したがって、この問題の原因は、並行して__running__テストケースです。 これは、一部を並列化できないものとしてマークしない限り、フィクスチャの下にあるすべてのテストケースを意味します。 これでは、単純なパラメーター化されていないテストと、パラメーター化されたテストの個々のケースが同等に扱われます。

OneTimeTearDownがないフィクスチャでテストの並列化を可能にすることは興味深い実験です(OneTimeSetUpは問題ないと思います)。 あなたがその決定を正しくすることができればそれは簡単に働くかもしれません。 ただし、OneTimeTearDownには継承されたメソッドとグローバルActionAttributesの両方を含めることができるため、決定は想像以上に困難です。

@ jnm2この特定の問題に取り組む機会はすでにありましたか?

@julianhaslingerいいえ。1885年と1933年の2つの差し迫った問題の後で、私のリストに載っています。それに取り組みたいのであれば、なおさらです。

@julianhaslingerお互いを知らないので、難しいと言って失礼します。 物事が現在どのように行われているのか、そしてその理由を必ず掘り下げてください。後者は必ずしも明白ではないのではないかと思います。 これを修正するために表示したい個別のPRの内訳については、 https: //github.com/nunit/nunit/issues/164#issuecomment-265267804のコメントを参照してください。 より単純なアプローチを思いついた場合は、コーディングする前にそれについて投稿してください。そうすれば、将来の考慮事項と、将来の予測に関係する明らかなYAGNIを比較検討できます。

@CharliePoole @ jnm2こんにちは、みんな!

この不足している機能の実装を開始したかったのではなく、単にその進捗状況を知りたかっただけです。 上記の回答からわかるように、この特定の機能のリクエストに関しては進展がありません(?)。

@CharliePooleコードの調査中に遭遇した潜在的な問題の1つは、現在のフィクスチャの処理方法でした。 現在、すべてのWorkItemは同じFixtureインスタンスにアクセスでき

これに対する1つの解決策は、各WorkItemをテストクラスの新しいインスタンスで動作させることですが、フィクスチャのインスタンスが1つではなくなるため、フィクスチャのセットアップの動作が複雑になる可能性があります。

@ chris-smith-zocdocはい、それがNUnitとその前身のjunitの最大の違いです。 当時、それは賛否両論で広く議論されていましたが、今はあまり取り上げられていません。 そのため、NUnitテストはステートレスであり、すべての初期化はSetUpメソッドで実行されるはずでした。

TestFixtureSetUp(現在はOneTimeSetUpと呼ばれています)が導入されると、より高価な初期化を1回実行して、すべてのテストを同じ初期化値で動作させることが可能になりました。 これは、テスト対象のクラスのインスタンスを作成するときに最も役立ちます。インスタンス自体はステートフルである可能性があります。 近年、ますます多くのユーザーがこの機能を利用しています。

テストケースごとにユーザーフィクスチャの個別のインスタンスを作成するオプションを追加するというテーマが定期的に発生します。 これまでのところ、計画された機能になる段階には到達していません。 これは、ユーザー側の並列メソッド機能の使いやすさに間違いなく関係していますが、実装とは直交していると思います。 インスタンスごとに新しいフィクスチャを作成する場合は、「1回」のセットアップを複数回実行するだけです。 もちろん、それは静力学を利用しているすべてのユーザーに大きな打撃を与えるでしょう。 😢

並列テスト方法を延期した理由は2つあります。(1)実装が難しいことと(2)並列フィクスチャは私たちにとっては簡単ですが、ほとんどのユーザーにとっては十分であるように思われたことです。 (オンラインディスカッションに基づいて)多くのユーザーがテストメソッド間で状態を共有しているように見えますが、複数のフィクスチャ間で状態を共有しているユーザーはほとんどいないようです。 これまでのところ、多くのユーザーが並列処理の機能を利用しており、メソッドの並列処理を非常にひどく望んでいるユーザーもいますが、比較的小さなグループのようです。

それでも、何かをする時が来たと思います。 少なくともいくつかの実験を実行し、おそらく他の人がフォローアップできるタスクの賢明な内訳を考え出す程度まで、私はこれを第1四半期に引き継ぐつもりです。

インスタンスごとに新しいフィクスチャを作成する場合は、「1回」のセットアップを複数回実行するだけです。 もちろん、それは静力学を利用しているすべてのユーザーに大きな打撃を与えるでしょう。

並列で実行することを選択した場合、静的状態と並列処理を混合するために何かが壊れた場合にそれがあなたの責任である限り、静的状態がないことを要求することは合理的だと思います。 幸いなことに、すべてのコードがテスト中なので、見逃すことは難しいはずです😆

それでも、何かをする時が来たと思います。 少なくともいくつかの実験を実行し、おそらく他の人がフォローアップできるタスクの賢明な内訳を考え出す程度まで、私はこれを第1四半期に引き継ぐつもりです。

そのために私を数えてください。

私も!

3:58 AMで2017年1月(土)、14日、ジョセフ・マッサー[email protected]
書きました:

>>
>>
>>
>>

[画像:Boxbe] https://www.boxbe.com/overview

自動クリーンアップ:最後の1通のメールを保持します([email protected]

ルールの編集
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ%252BtolspNKBzqBxtH6H%252FhqnTQ%253D%253D&tc_serial = 28420100882&tc_rand = 128339648&utm_source = stf&utm_medium = email&utm_campaign =

| ルールを削除する
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ%252BtolspNKBzqBxtH6H%252FhqnTQ%253D%253D&tc_serial = 28420100882&tc_rand = 128339648&utm_source = stf&utm_medium = email&utm_campaign =

| 重要なマーク
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Dwa43L7bW5j4V5ymh5QXh%252FNXk%252F0KVSSFJSqwHw2yu4No%253D%26token%3DjkWoQ96YyOE%252FHA7PvZA8g%252FOAgpOQMZdIE7ophiWCxqx1y6zZCFJ%252FKSZ2WZELsWD3YQoDEdjwb%252BWo6wGi4xiUEkGngbggedv8iYBxU7zk% 252FJamyOuVtPzie4dhQJXQkQQ%252BtolspNKBzqBxtH6H%252FhqnTQ%253D%253D%26important%3Dtrue%26emlId%3D54854949581&tc_serial = 28420100882&tc_rand = 128339648&utm_source

インスタンスごとに新しいフィクスチャを作成する場合は、単に「1つ」を実行します。
時間の設定が複数回あります。 もちろん、それは
静力学を利用する。

あなたが静的な状態がないことを要求することは合理的だと思います
何かがあればそれがあなたのせいである限り、並行して実行することを選ぶ
静的状態と並列処理を混合するためのブレーク。 幸いなことに、このすべてのコードは
テスト中なので見逃しにくいはずです:D

それでも、何かをする時が来たと思います。 私はこれを引き受けるつもりです
第1四半期は、少なくともいくつかの実験を実行する程度まで
そしておそらく他の人ができるタスクの賢明な内訳を思い付く
フォローアップ。

そのために私を数えてください。


あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/nunit/nunit/issues/164#issuecomment-272488655 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAHNVlwVps8pQ93UIwZw6zY7TOyHO0a6ks5rR61EgaJpZM4CUZ8r

いくつかのタイミングテストを実行して、私は何か面白いものを発見しました。 テストケースを並列化可能と呼ぶことにはあいまいさがあります。 これは備品や他のスイートにも当てはまるかもしれませんが、それほど明白ではありません。

メソッドが完全に並列化できない場合、それは__他のメソッド__と並列に実行できないことを意味します。 OTOH、フィクスチャ内で並列化できない場合は、__同じフィクスチャ内の他のメソッドと並行して実行することはできません。__

この区別を次のように処理することを提案します。

  1. テストメソッドにParallelizable属性がない場合、他の属性(Apartmentなど)が別のスレッドで実行するように要求しない限り、テストメソッドはそれを含むフィクスチャと同じスレッドで実行する必要があります。

  2. スコープがSelfのParallelizable属性がある場合、または上位レベルのスイートが子のスコープを指定している場合、テストメソッドはフィクスチャ内の他のメソッドと並行して実行されます。

@ nunit / core-teamの考え?

上で省略:

  1. スコープがNoneのParallelizable属性がある場合、非並列キューで実行されます。

@ CharliePoole-あなたの3つのポイントは理にかなっていますが、私たちがやらないことを提案しているという代替案が何であるかはわかりません。 明確にしていただけますか?

現在、属性を持たないことは、ParallelScope.Noneを使用することと同じように扱います。 ディスパッチを有効にすると、非並列キューのキューに入れられ、テストの実行が大幅に遅くなります。

PR#2011は、この機能の実装に向けていくつかの最初のステップを実行しますが、テストケースをそれらを含むフィクスチャのスレッドで実行するように強制する#defineが含まれています。 このコメントは、その制限を取り除くために私がしなければならないと思うことを文書化しています。

現在、フィクスチャのOneTimeTearDownは、最後に実行されたテストケースを終了するために使用されたスレッドで実行されます。 テストケースが並行して実行される場合、どのテストケースになるかを予測することはできません。 フィクスチャに必要な特性とは異なる特性のスレッドである可能性があります。 たとえば、終了する最後のテストがSTAで実行されている場合、OneTimeSetUpがMTAで実行されていても、それがOneTimeTearDownの実行に使用されます。 多くの場合、それは問題を引き起こさないかもしれませんが、場合によっては問題を引き起こす可能性があります。

これは実際には高レベルのフィクスチャでも問題になる可能性がありますが、並列テストケースの導入は、エラーの原因となる不一致の可能性がさらに多くなることを意味します。

したがって、フィクスチャの分解が正しい種類のスレッドで行われるようにするために、最後に実行したテストのスレッドでフィクスチャを実行することはできなくなりました。 代わりに、ディスパッチャは、保留中のすべてのティアダウンに関する情報を維持し、適切なスレッドで適切なタイミングでそれらのティアダウンを実行するように通知される必要があります。 その方法を理解することが、この機能の「設計」フェーズです。

最初から(2014年に)このスレッドをフォローしていて、この機能の追加を待っている間に独自の回避策を実装したくない、または実装できない人のために、NUnit2.6.3を使用した実装に出くわしました。非常に簡単に使用できるように見えるCodePlex(複数の並列スレッドで機能テストを実行する際に機能することを確認しました)。

http://cpntr.codeplex.com/

このメッセージがこのスレッドに関する最近の議論と少し直交している場合は、事前に@CharliePooleに謝罪しますが、NUnit 3に向けて設定された約束に基づいて、この機能の追加を過去3年間待っている人がいる場合は、日)、私はあなたたちが設計の問題を解決することができるまでそれが解決策を提供するかもしれないと思います(あなたが解決策に近づいているように聞こえます)。

@CharliePoole

したがって、フィクスチャの分解が正しい種類のスレッドで行われるようにするために、最後に実行したテストのスレッドでフィクスチャを実行することはできなくなりました。 代わりに、ディスパッチャは、保留中のすべてのティアダウンに関する情報を維持し、適切なスレッドで適切なタイミングでそれらのティアダウンを実行するように通知される必要があります。 その方法を理解することが、この機能の「設計」フェーズです。

保留中の分解アイテムを事前にディスパッチャに知らせる必要がありますか、それとも利用可能になったときにディスパッチャにディスパッチできますか? より具体的には、CompositeWorkItemが現在PerformOneTimeTearDownを呼び出している場合、ディスパッチャーを使用して新しい作業単位を正しい作業シフトにディスパッチできますか?

@ chris-smith-zocdocはい、まさにそれが私がやっていることです。 新しいタイプの作業項目OneTimeTearDownWorkItemを作成しました。これは、 CompositeWorkItemネストされ、最後の子テストが実行されたときにディスパッチされます。 後で、OneTimeSetUpとすべてのテストが同じスレッドで実行されたときのいくつかの効率を確認する可能性があります。

すべてを注意深く読んでいませんが、この機能の一部として要求したいことの1つは、特にI / Oバウンドテストの場合、並列処理が「スマート」であることです。 たとえば、10個のスレッドが100個の並列化可能なテストを実行している場合、10個のスレッドが座って、最初の10個のテストが完了するのを待ってから、次の10個のテストに進むことはありません。 最初の10個のテストが非常に長時間実行されるI / Oタスクの待機を開始した場合、スレッドは他のテストに自由に移動できるはずです。 I / Oタスクが完了すると、スレッドが解放されると、スレッドは待機中のテストを再開します。

基本的に、async / awaitを多用するI / Oバウンドテストのスマートスループット管理を求めています。 これは、テストにおける私たちの最大のボトルネックです。

@ chris-smith-zocdoc実際、それは私がやっていることとほとんど同じです。 私は基本的に、既存のカウントダウンメカニズムを使用して、1回限りのティアダウンタスクのディスパッチをトリガーしています。 秘訣は、適切なキューにディスパッチすることです。

@gzak並列実行のメカニズムはすでに存在することに

誰かがそれがどのように機能するかを私に説明できますか?
テストクラスがあります
このクラスのテストを並行して実行しないと、すべてのテストに合格しました
しかし、[Parallelizable(ParallelScope.Children)]で実行すると
したがって、それらは並行して実行されます(同じクラスの複数のメソッド)
しかし、何らかの理由でいくつかのテストが失敗しています。
このクラスにはテスト全体で使用されるインスタンスフィールドがあり、それらのフィールドはスレッド間で共有されているようです
私は正しいですか?
そのクラスのインスタンスを1つだけ作成し、この単一のオブジェクトでメソッドを同時に呼び出しますか?
CharliePoole

あなたはそれを理解しました! はい、フィクスチャ内のすべてのテストは同じインスタンスを使用します。 これは、常にそのように機能してきたNUnitの歴史です。 テストケースを並行して実行するか、テストごとに変更される状態にするかを選択する必要があります。 現在、それを回避する方法はありません。

とはいえ、フィクスチャの比率が適切な場合は、フィクスチャを並列に実行するだけで優れたパフォーマンスが得られます。

[Parallelizable(ParallelScope.Children)]を中に含めることは可能です
AssemblyInfo.csファイル?

誰かがそれが機能しているのを見たことがありますか?

1時37時2017年6月14日、CharliePooleの[email protected]書きました:

[画像:Boxbe] https://www.boxbe.com/overview自動クリーンアップ:維持
最後の1通のメール([email protected])ルールの編集
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D&tc_serial = 30872123699&tc_rand = 2087335475&utm_source = stf&utm_medium = email&utm_campaign = ANNO_CLEANUP_EDIT&utm_content = 001
| ルールを削除する
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D&tc_serial = 30872123699&tc_rand = 2087335475&utm_source = stf&utm_medium = email&utm_campaign = ANNO_CLEANUP_EDIT&utm_content = 001
| 重要なマーク
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DCCP9ir0TebdbdQOWVtGMQyr2TETYOrzfkbItPzUTgDk%253D%26token%3D0PvYtf1G2B%252FJ2FNN3b7MTSmP1zvs6x3Cu8z6LaAB8%252BJm73uy8ZNUCnQcknlgWKxRQ5zjE%252BY30Xkv1W1Gue9gGnpyi72YUTaHP2h6wvuEpTXe1WoQDoSHpUGDQefgQu6LDH0rRhsEvF%252FW%252BhysbMtsDw%253D% 253D%26important%3Dtrue%26emlId%3D61187554820&tc_serial = 30872123699&tc_rand = 2087335475&utm_source = stf&utm_medium = email&utm_campaign = ANNO_CLEANUP_EDIT&utm_content = 001

あなたはそれを理解しました! はい、フィクスチャ内のすべてのテストは同じインスタンスを使用します。
これは、常にそのように機能してきたNUnitの歴史です。 絶対です
テストケースを並行して実行するか、次のような状態にするかを選択します
テストごとに変更されます。 現在、それを回避する方法はありません。

とは言うものの、フィクスチャの割合が適切であれば、単に実行するだけです
並列のフィクスチャは、優れたパフォーマンスを提供します。


あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/nunit/nunit/issues/164#issuecomment-308157832 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAHNVuK-J-X74mlAA_eT7OX7dxs7MpoRks5sDqzLgaJpZM4CUZ8r

@agrayはい、実際、それが私が現在AssemblyInfo.csを持っている唯一の理由です。

こんにちはジョセフ、

AssemblyInfo.csファイルに追加する並列処理行は何ですか?

何が機能するのか知りたいです。

乾杯、

アンドリュー

16:17の水曜日、2017年6月14日には、ジョセフ・マッサー[email protected]
書きました:

[画像:Boxbe] https://www.boxbe.com/overview自動クリーンアップ:維持
最後の1通のメール([email protected])ルールの編集
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D%253D&tc_serial = 30882364582&tc_rand = 1974513896&utm_source = stf&utm_medium = email&utm_campaign = ANNO_CLEANUP_EDIT&utm_content = 001
| ルールを削除する
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D%253D&tc_serial = 30882364582&tc_rand = 1974513896&utm_source = stf&utm_medium = email&utm_campaign = ANNO_CLEANUP_EDIT&utm_content = 001
| 重要なマーク
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DnRGYOf%252FKR68McP8RTipuFTLF9WUvAkSKSh6OYJYvJ2w%253D%26token%3DDcwWzMT9yPtQLckdXD3BLhW5xAB%252BMpc9XdsrbBlwdQJZC%252Bjo3SjsyMVC8vese%252BCNRw2IyucWqEcHR5Is7CK7nx01VuSQESvjG4ZUj%252B2Cfcwg51yUFFQJSwrmTVxqAk4%252BTVGDSrnutdAuqiJ3kTaYQA% 253D%253D%26important%3Dtrue%26emlId%3D61214070592&tc_serial = 30882364582&tc_rand = 1974513896&utm_source = stf&utm_medium = email&utm_campaign = ANNO_CLEANUP_EDIT&utm_content = 001

@array https://github.com/arrayはい、実際、それが私が唯一の理由です
今AssemblyInfo.csを持っています。


あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/nunit/nunit/issues/164#issuecomment-308325726 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAHNVghNAX8CJkqAy-qhAz8bXNhZcFOQks5sD3NigaJpZM4CUZ8r

@agrayあなたが尋ねたもの:

c# [Parallelizable(ParallelScope.Children)]

ターゲットを忘れないでください

[assembly: Parallelizable(ParallelScope.Children)]

@LirazShay NUnitを使用してSeleniumテストを駆動し、フィクスチャレベルのフィールドを使用して、ユーザーアカウントや、使用していたSelenium WebDriverインスタンスへの参照などを保持していたため、フィクスチャ内でテストを並行して実行できませんでした。 私が回避した方法は、IDisposableを実装する「ファクトリ」(正しい用語かどうかわからないため引用符を使用)を作成することでした。IDisposableは、テストごとにすべてのテストニーズをカプセル化し、最後にそれらをきれいに破棄します。 [TearDown]や[OneTimeTearDown]のようなものを必要とせずにテストします。

 public class TestFactory : IDisposable
    {
    // Instantiate a new SafeHandle instance.
    private readonly System.Runtime.InteropServices.SafeHandle handle = new Microsoft.Win32.SafeHandles.SafeFileHandle(IntPtr.Zero, true);

    // Flag: Has Disposed been called?
    private bool disposed = false;

    public TestFactory()
    {
        this.UserRepository = new List<UserAccount>();
        this.DU = new DataUtility();
    }

    // A list of users created for this test
    public List<UserAccount> UserRepository { get; private set; }

    // A very simple data layer utility that uses Dapper to interact with the database in my application 
    public DataUtility DU { get; private set; }

    // Gets a new user and adds it to the repository
    public UserAccount GetNewUser()
    {
        var ua = new UserAccount();
        this.UserRepository.Add(ua);
        return ua;
    }


    public void Dispose()
    {
        this.Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (this.disposed)
        {
            return;
        }

        if (disposing)
        {
            // Deletes all user accounts created during the test
            foreach (UserAccount ua in this.UserRepository)
            {
                try
                {
                    ua.Delete();
                }
                catch (Exception)
                {
                    // Take no action if delete fails.
                }
            }

            this.DU.DeleteNullLoginFailures(); // Cleans up the database after tests
            Thread.Sleep(1500);
        }

        this.disposed = true;
    }
}

次に、テスト内でこれを行うことができます:

[TestFixture]
public class UserConfigureTests
{
    [Test]
    public void MyExampleTest()
    {
        using (TestFactory tf = new TestFactory())
        {
            var testUser = tf.GetNewUser();

    tf.DU.DoSomethingInTheDatabase(myParameter);

    // Test actions go here, and when we exit this using block the TestFactory cleans
    // up after itself using the Dispose method which calls whatever cleanup logic you've written into it
        }
    }
}

このようにして、多くのコードの重複を回避できます。テストの依存関係を変更する必要がある場合は、ファクトリで1回だけ実行します。 私が取った戦略について誰かがフィードバックを持っているなら、私はそれをいただければ幸いです!

@tparikka私はまさにそのアプローチを自分自身に強くお勧めします。

AssemblyInfoファイルに次のものがあります。

[アセンブリ:Parallelizable(ParallelScope.Children)]
[アセンブリ:LevelOfParallelism(16)]

LevelOfParallelism属性ももう必要ですか?

午前4時37分に2017年6月15日、ジョセフ・マッサーの[email protected]書きました:

[画像:Boxbe] https://www.boxbe.com/overview自動クリーンアップ:維持
最後の1通のメール([email protected])ルールの編集
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D&tc_serial = 30894750852&tc_rand = 1847060911&utm_source = stf&utm_medium = email&utm_campaign = ANNO_CLEANUP_EDIT&utm_content = 001
| ルールを削除する
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D&tc_serial = 30894750852&tc_rand = 1847060911&utm_source = stf&utm_medium = email&utm_campaign = ANNO_CLEANUP_EDIT&utm_content = 001
| 重要なマーク
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3Doth%252FFbAPG%252FhDbtUlS0i2PDDdQ0lP4dBi8o7QQmkLEMQ%253D%26token%3DHe7HfTrm%252Fiba3yIDazaBx8JO9NrmoL8p5TWtDB1hUxq0qp%252BhCRCB3OSl7sUQ6wDshc2I5LQhbR2jszLWr6FnRy%252FZUrCqghZIIilbDWKszT7pkI44xp9vaL6cszH9Sgg1YPCAHdVWqccZYxYXGW174A%253D% 253D%26important%3Dtrue%26emlId%3D61245244440&tc_serial = 30894750852&tc_rand = 1847060911&utm_source = stf&utm_medium = email&utm_campaign = ANNO_CLEANUP_EDIT&utm_content = 001

@tparikkahttps ://github.com/tparikka私はまさにそれを強くお勧めします
自分に近づく。


あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/nunit/nunit/issues/164#issuecomment-308521058 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAHNVmEzVDbw32Xx0jkYcGK9bZW3tLvXks5sECh8gaJpZM4CUZ8r

LevelOfParallelism使用についてはまだ検討していません。 デフォルトでは、使用しているコアの数になります。

テストがCPUにバインドされていない場合は、高い方が理にかなっています。 しかし、いつものようにパフォーマンスでは、答えはシナリオに大きく依存するため、推測するよりも測定する方がよいでしょう。

@CharliePoole TestcaseSourceを使用していますが、結果のテストケースは実際には並行して実行されていないようです。 このようなものが機能することが期待されていますか?

`` `c#
[テストフィクスチャ]
クラスの逆シリアル化
{{
public static IEnumerableShouldDeserializeAllCases()=> Enumerable.Repeat(0、5).Select(x => TimeSpan.FromSeconds(2));

    [TestCaseSource("ShouldDeserializeAllCases"), Parallelizable(ParallelScope.Children)]
    public void ShouldDeserializeAll(TimeSpan t)
    {
        Thread.Sleep(t);
        Assert.AreEqual(1, 1);
    }
}

`` `

全体の所要時間は、約2秒ではなく10秒です。

子供はいないと思いますので、この場合はもっと利用したほうがいいと思います
[Parallelizable(ParallelScope.All)]
または、属性をクラスレベルで移動します。

@ParanoikCZEありがとう。 私は実際にその属性が何を意味するかに関して盲目的に飛んでいるので、そこですべての列挙値を試しました。 AllChildrenFixtureSelfを使用しても、実行時間は10秒になります(少なくともVisual Studioでは)。

クラスに移動してみましたが、どちらも役に立たないようです。

これがインスピレーションの源です:)

class Deserialization
{
    public static IEnumerable<TestCaseData> ShouldDeserializeAllCases
    {
        get
        {
            for (int i = 1; i <= 5; i++)
                yield return new TestCaseData(TimeSpan.FromSeconds(i)).SetName($"Thread_worker_{i}");
        }
    }

    [TestCaseSource(nameof(ShouldDeserializeAllCases)), Parallelizable(ParallelScope.Children)]
    public void ShouldDeserializeAll(TimeSpan t) => System.Threading.Thread.Sleep(t);
}

@ParanoikCZEありがとうございます。 これをVisualStudioでテストしたところ、視覚化ははるかに明確になりましたが、テストは引き続き順次実行されています。 ステップを増やすのではなく、テストケースごとに一定のスリープを使用すると、これがわかりやすくなります。

[assembly:LevelOfParallelism(5)]をAssemblyInfoに追加してみてください。デフォルト値があると思いますが、どういうわけかうまくいかない可能性があります。 とにかく、私はアイデアがありません。 :)

このページは役に立ちましたか?
0 / 5 - 0 評価