Nunit: NUnit3.8 +はテストの実行を終了しません

@DavidZidarテストを並列化する方法の詳細を追加できますか？ フィクスチャ/テストケースによって？ 並列アイテムと非並列アイテムが混在していますか？

これは、3.8にあったhttps://github.com/nunit/nunit/issues/2261に関連している可能性があるようです。

ああ...昨日、3.8.0でReSharperを介してテストを実行しているのを見たと思います。

[assembly: Parallelizable(ParallelScope.Fixtures)]を、新しい[NonParallelizable]属性を使用する並列実行できないいくつかのテストと組み合わせて使用​​しています。

--workers = 1を指定してコンソールランナーを実行しようとしましたが、違いはありませんでした。

@DavidZidar

並列フィクスチャと非並列アイテムの組み合わせが重要に聞こえます。 いくつかの属性を削除して実験し、再現可能な最小限の例を見つけることができるかどうかを確認できれば、非常に役立ちます。

なんらかの理由で2x [SetUp]メソッドと1つの[TearDown]があり、 [OneTimeSetUp]と[OneTimeTearDown]もある、問題のあるパラグラフ化できないテストフィクスチャを1つ見つけました。 このクラスを削除すると、CodeRushテストランナーは毎回終了するように見えますが、コンソールランナーは、少なくとも2回は完了しましたが、ほとんどの場合フリーズし続けます。

残念ながら、新しいプロジェクトでこの問題を再現することはできません。このプロジェクトはかなり大きく、コードを共有することはできません。

また、テストを何度も実行しているので、 [NonParallelizable]マークされた他のいくつかのテストは、並行して実行されているはずではないのに、時々ランダムに失敗します。

もう1つ試してみました。 [NonParallelizable]属性を持つ23のテストフィクスチャをすべて削除しましたが、これは事態をさらに悪化させました。 現在、CodeRushは、ロックアップする前にテストの10％を通過することすらしていません。 コンソールランナーがどこまで到達できるかわかりません。 合計で約370のフィクスチャと3000のテストがあります。

バージョン3.8.0以降、同じ動作が発生しました。 バージョン3.7.1にダウングレードした後。 すべてが再び正常に動作します。 resharperテストランナーとVisualStudioテストランナーを使用しました。 どちらも同じ動作をしました。 すべてのテストを実行すると、実行がデッドロックに陥ったようです。 テストを個別に実行すると、すべてのテストが正しく実行されます。

私のテストは次のようになります。 userControlを作成し、プリズムビューモデルロケーターによってデータコンテキストを正しく作成できるかどうかを確認するだけです。

    [Apartment(ApartmentState.STA)]
    public class GuiCreationTests
    {
        private TestBootstrapper testBootStrapper;

        private App app;

        [SetUp]
        public void SetupTests()
        {
            testBootStrapper = new TestBootstrapper();
            testBootStrapper.Run();

            if (Application.Current == null)
            {
                app = new App();
                app.InitializeComponent();
            }
        }

        [Test]
        public void CreateMemoryViewWithDataContextCorrectly()
        {
            ViewShouldHaveCorrectDataContext<MemoryView, MemoryViewModel>();
        }

        [Test]
        public void CreateSensorsViewWithDataContextCorrectly()
        {
            ViewShouldHaveCorrectDataContext<SensorsView, SensorsViewModel>();
        }

        [Test]
        public void CreateRegisterViewWithDataContextCorrectly()
        {
            ViewShouldHaveCorrectDataContext<RegisterView, RegisterViewModel>();
        }

        [Test]
        public void CreateRegimeViewWithDataContextCorrectly()
        {
            ViewShouldHaveCorrectDataContext<RegimeView, RegimeViewModel>();
        }

        [Test]
        public void CreateFlashViewWithDataContextCorrectly()
        {
            ViewShouldHaveCorrectDataContext<FlashView, FlashViewModel>();
        }

        private void ViewShouldHaveCorrectDataContext<TView, TViewModel>()
            where TView : UserControl, new() where TViewModel : BaseViewModel
        {
            var sut = (UserControl)new TView();
            sut.DataContext.Should().NotBeNull();
            sut.DataContext.Should().BeOfType<TViewModel>();
        }
    }

@Maradaehneテストで何らかの並列処理を使用していますか？

現時点では、並列処理はないはずだと思います。 明日仕事中にビューモデルがタスクを作成するかどうかを確認する必要があります。 それがあなたが知りたかったことなら。

私はNUnitの並列処理について言及していました。 サンプルコードにはParallelAttribute指定されていませんが、たとえば、アセンブリ属性として、より高いレベルで存在する可能性があります。

いいえ、 ParallelAttributeは使用しません

@Maradaehneあなたはここで並列処理に関する問題に便乗しています。 😄だからあなたの問題は何か違うものです。 最初にここでいくつかの修正を試すことができますが、それらが機能しない場合は、別の問題を提出する必要があります。

あなたの問題がSTAの使用に関連しているか、 TestBootstrapperがそれを引き起こす何かをしているように私には見えます。 その呼び出しの目的は何ですか？ なぜそれを複数回実行したいのですか？ 実行を継続しますか？ （その場合、あなたはそれを終了する必要があります）

STAをWRTし、フィクスチャで要求されているように、STAで実際に実行されていることを確認する小さなテストを作成します。 おそらく、並列実行がないのですが、確認しましょう。

こんにちは。テストもNUnit3.8 +でハングし始めたので、これに飛びつきます。[assembly：Parallelizable（ParallelScope.Fixtures）]も使用しています。 現在のところ、NonParallelizable属性は試していません。

それが役立つかどうかを確認するために使用されるセットアップと分解の方法を調査する必要があります。 テストの継承が行われているため、少し面倒です。

これもhttps://github.com/nunit/nunit/pull/2445で修正されることを願ってい

誰かが修正をテストできる場合は、Appveyorからダウンロードできます： https ：//ci.appveyor.com/project/CharliePoole/nunit/build/3.9.0-ci-04450-issue-2438/artifacts

3.9.0-ci-04450-issue-2438ビルドをテストしたところ、かなり改善されているように見えますが、まだありません。

CodeRushテストランナーは毎回完了するようです。これは問題ありませんが、 Parallelizable(ParallelScope.None)属性を使用したテストのいくつかはランダムに失敗し、NUnit3.5.0を使用している間これらのテストは数か月間正常に機能しています。

コンソールランナーはまだ時々ロックします。

@DavidZidarに感謝します。 @rprouseは、そのPRでいくつかの追加の問題を発見しました、私たちはもっと見る必要があると思います。

以前と同じように、再現可能な例を見つけることができれば、それは非常に貴重です。 https://github.com/nunit/nunit/issues/2438で明らかになった問題を修正しましたが、より大きなテストスイートがさまざまなシナリオにぶつかる可能性があるようです。

また、並行して実行される非並列テストについても興味をそそられます。 --trace=Verboseを使用して、いくつかのログを作成できますか。 必要に応じて匿名化できますが、これらは、非並列テストが並列で実行されている場合に何が起こっているかについてのビューを提供するはずです。 （ログから明確にならない可能性がある、非並列にする必要があるテストも含めてください！）

編集：3.9.0-ciビルドに対してこれを行ってください-うまくいけば正しい方向に進んでいます。

申し訳ありませんが、明確ではありませんでした。一部のアサーションは、並行して実行されない限り実際には失敗しないはずの一部のテストでランダムに失敗し、一部のテストでは、実際には失敗しないときにNullReferenceExceptionがスローされます。

たとえば、一部のテストではMVCからDependencyResolver.Currentを構成する必要があり、そのようなテストの1つは、nullに戻された、または他のテスト用に別のサービスで再構成されたようにリゾルバーを使用している場合、NullReferenceExceptionで失敗することがあります。

質問ですが、 Parallelizable(ParallelScope.None)マークされたテストは、プロセスごとに現在実行されている唯一のテストであることが保証されていますか？ この特定のテストのセットアップと実行の間に、他のセットアップまたはティアダウンメソッドが呼び出されたように思われるためです。

明確にしていただきありがとうございます。 🙂

質問ですが、Parallelizable（ParallelScope.None）でマークされたテストは、プロセスごとに現在実行されている唯一のテストであることが保証されていますか？ この特定のテストのセットアップと実行の間に、他のセットアップまたはティアダウンメソッドが呼び出されたように思われるためです。

それが理論です、はい。 3.8ではこれにいくつかの問題があるようですが、テストケースを並行して実行できるように変更されています。

2つのこと：
1） Parallelizable(ParallelScope.None)をどのように使用しているかを明確にできますか？それはテストフィクスチャですか、それとも個々のテストですか？
2）上記のように-ログファイルを見て、テストが誤って並行して実行されていることが間違いなく問題であることを確認できるはずです。 （可能性が非常に高いように聞こえますが、さらに掘り下げる前に再確認することをお勧めします！）

個々のテストではなく、フィクスチャの属性のみを使用しています

これは、実際には失敗してはならないアサーションが失敗したテストの単一の匿名化されたテストスイートノードです。

              <test-suite type="TestFixture" id="0-1815" name="" fullname="" classname="" runstate="Runnable" testcasecount="11" result="Failed" site="Child" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.219772" total="11" passed="10" failed="1" warnings="0" inconclusive="0" skipped="0" asserts="11">
                <properties>
                  <property name="ParallelScope" value="None" />
                </properties>
                <failure>
                  <message><![CDATA[One or more child tests had errors]]></message>
                </failure>
                <test-case id="0-1817" name="" fullname="" methodname="" classname="" runstate="Runnable" seed="1397646013" result="Passed" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.017836" asserts="1" />
                <test-case id="0-1818" name="" fullname="" methodname="" classname="" runstate="Runnable" seed="841770727" result="Passed" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.012288" asserts="1" />
                <test-case id="0-1816" name="" fullname="" methodname="" classname="" runstate="Runnable" seed="419323190" result="Passed" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.016657" asserts="1" />
                <test-case id="0-1826" name="" fullname="" methodname="" classname="" runstate="Runnable" seed="1469933891" result="Passed" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.007956" asserts="1" />
                <test-case id="0-1822" name="" fullname="" methodname="" classname="" runstate="Runnable" seed="1086752121" result="Passed" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.021974" asserts="1" />
                <test-case id="0-1824" name="" fullname="" methodname="" classname="" runstate="Runnable" seed="1083353855" result="Passed" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.005639" asserts="1" />
                <test-case id="0-1823" name="" fullname="" methodname="" classname="" runstate="Runnable" seed="1593973579" result="Passed" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.004108" asserts="1" />
                <test-case id="0-1825" name="" fullname="" methodname="" classname="" runstate="Runnable" seed="999831506" result="Passed" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.022739" asserts="1" />
                <test-case id="0-1819" name="" fullname="" methodname="" classname="" runstate="Runnable" seed="2106953889" result="Passed" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.009117" asserts="1" />
                <test-case id="0-1821" name="" fullname="" methodname="" classname="" runstate="Runnable" seed="85741110" result="Passed" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.007146" asserts="1" />
                <test-case id="0-1820" name="" fullname="" methodname="" classname="" runstate="Runnable" seed="379361616" result="Failed" start-time="2017-09-18 16:01:01Z" end-time="2017-09-18 16:01:01Z" duration="0.023703" asserts="1">
                  <failure>
                    <message><![CDATA[  Expected: 0
  But was:  2
]]></message>
                    <stack-trace><![CDATA[   at SomeTest() in SomeTest.cs:line 104
]]></stack-trace>
                  </failure>
                  <assertions>
                    <assertion result="Failed">
                      <message><![CDATA[  Expected: 0
  But was:  2
]]></message>
                      <stack-trace><![CDATA[   at SomeTest() in SomeTest.cs:line 104
]]></stack-trace>
                    </assertion>
                  </assertions>
                </test-case>
              </test-suite>

興味深いことに、開始時間と停止時間はすべて同じですが、それが何かを意味するかどうかはわかりません。 NUnit3.5は同じように動作するようです。

申し訳ありませんが、ログのコメントがはっきりしていなかったと思います。

NUnitコンソールのコマンドラインで引数--trace=Verboseを渡します。 これにより、多数の.logファイルが作成されます。そのうちの1つは、どのテストがどのワーカースレッドでどの順序で実行され、どのように並列化されたかを詳しく説明します。 角括弧内の番号は、ワーカー番号に関連しています。以下の例を参照してください。

12:54:30.324 Debug [10] Dispatcher: Using Direct strategy for Test
12:54:30.324 Debug [10] Dispatcher: Using Parallel strategy for Test(1)
12:54:30.324 Debug [10] Dispatcher: Using Parallel strategy for Test(2)
12:54:30.324 Info  [ 4] TestWorker: Worker#1 executing Test(1)
12:54:30.324 Info  [ 8] TestWorker: Worker#5 executing Test(2)
12:54:30.324 Debug [10] Dispatcher: Using Parallel strategy for Test(3)
12:54:30.324 Debug [10] Dispatcher: Using Parallel strategy for Test(4)
12:54:30.324 Info  [ 5] TestWorker: Worker#2 executing Test(3)
12:54:30.324 Info  [11] TestWorker: Worker#8 executing Test(4)

このファイルから、非並列であると予想されるテストが他のテストと並行して実行されているかどうかを確認できるはずです。

そうそう。 最初はログファイルが表示されませんでした。

これは匿名化されたスニペットです。失敗したテストはスレッド22で実行されており、フィクスチャがParallelizable(ParallelScope.None)マークされていても、この特定のフィクスチャのすべてのテストに「直接戦略」を使用しているようです。

09:44:03.978 Info  [22] TestWorker: Worker#NP executing ShouldBeNonParallelTests
09:44:03.978 Info  [22] Dispatcher: Saving Queue State for ShouldBeNonParallelTests
09:44:03.978 Debug [22] WorkItemQueue: ParallelQueue.1 pausing
09:44:03.978 Info  [22] WorkItemQueue: ParallelQueue.2 starting
09:44:03.978 Debug [22] WorkItemQueue: ParallelSTAQueue.1 pausing
09:44:03.978 Info  [22] WorkItemQueue: ParallelSTAQueue.2 starting
09:44:03.977 Info  [15] TestWorker: Worker#7 executing SomeOtherTests
09:44:03.978 Debug [22] WorkItemQueue: NonParallelQueue.1 pausing
09:44:03.978 Info  [22] WorkItemQueue: NonParallelQueue.2 starting
09:44:03.978 Debug [22] WorkItemQueue: NonParallelSTAQueue.1 pausing
09:44:03.978 Info  [22] WorkItemQueue: NonParallelSTAQueue.2 starting
09:44:03.978 Debug [18] Dispatcher: Using Direct strategy for OtherTestThatCanBeRunInParallel
09:44:03.978 Debug [20] Dispatcher: Using Direct strategy for OtherTestThatCanBeRunInParallel
09:44:03.978 Debug [17] Dispatcher: Using Direct strategy for OtherTestThatCanBeRunInParallel
09:44:03.978 Debug [ 9] Dispatcher: Using Direct strategy for OtherTestThatCanBeRunInParallel
09:44:03.978 Debug [15] Dispatcher: Using Direct strategy for OtherTestThatCanBeRunInParallel
09:44:03.978 Debug [16] Dispatcher: Using Direct strategy for OtherTestThatCanBeRunInParallel
09:44:03.978 Debug [14] Dispatcher: Using Direct strategy for OtherTestThatCanBeRunInParallel
09:44:03.978 Debug [ 9] Dispatcher: Using Direct strategy for OtherTestThatCanBeRunInParallel
09:44:03.977 Info  [19] TestWorker: Worker#11 executing SomeMoreTests
09:44:03.979 Debug [22] Dispatcher: Using Direct strategy for Test_1_from_ShouldBeNonParallelTests
09:44:03.980 Debug [19] Dispatcher: Using Direct strategy for OtherTestThatCanBeRunInParallel
09:44:03.980 Debug [19] Dispatcher: Using Direct strategy for OtherTestThatCanBeRunInParallel
...
09:44:05.045 Debug [22] Dispatcher: Using NonParallel strategy for ShouldBeNonParallelTests OneTimeTearDown
09:44:05.045 Info  [22] TestWorker: Worker#NP executing ShouldBeNonParallelTests OneTimeTearDown

これだけでは不十分な場合は、生のログファイルを非公開でメールで送信できます。

直接戦略は、属性のないテストに適しています。 これは、新しいキューエントリを作成せずに、同じスレッドで実行することを意味します。

スレッド22に散在する他のテストは、同じフィクスチャでの並列テストであると思います。

ああ、わかりました。

いいえ、他のスレッドでのテストは他のフィクスチャからのものです。

次に、なぜそれらが実行されているのかを理解する必要があります。 フィクスチャが並列化できない場合は、他のフィクスチャを同時に実行しないでください。

試す...

1. ParallelScope.NoneではなくNonParallelizableを使用します。 同じである必要がありますが、バグが発生する可能性があります。

2. フィクスチャとそれを含むスイートのすべての並列属性をアセンブリまでリストします。

1. それを試してみましたが、私が知る限り何の違いもありませんでした
2. AssemblyInfo.csには[assembly: Parallelizable(ParallelScope.Fixtures)]あり、いくつかのフィクスチャにはNonParallelizable属性があります。それだけです。

それは問題を絞り込みます。 非並列フィクスチャは、他の1つまたは複数のフィクスチャと並列に実行されています。 吊り下げは二次的な効果です。

理想的には、3.7.1で実行し、 --trace:Verboseからの出力を調べることによって、上記を確認できればよいでしょう。 一緒に実行されている単一の非並列フィクスチャからのテストのみが表示されます。

その場合は、次に、フィクスチャがNPフィクスチャと並行して誤って実行されるかどうかに共通点があるかどうか、またはディスパッチャのより一般的な問題であるかどうかを調べることができます。

そうです、3.7.1で実行してみましたが、毎回問題なくテストが実行されます。 私が見ている違いは、3.7.1は、並列化できないすべてのテストを、常に実行しているように見える3.8+とは異なり、最後に1つのスレッドで直列に実行しているように見えることです。

このような単純な状況（ほとんどのフィクスチャは、いくつかの非並列で並列化可能なテストケースと並列ではありません）では、それが発生するはずです。 すべての並列化可能なフィクスチャは、並列化不可能なフィクスチャを完了する必要があります。

@ChrisMaddockこれは私にとって鍵のようです。 コーナーケースにいくつかの修正を加えましたが、非常に単純なケースを台無しにしたようです。

@DavidZidar問題＃2454を参照してください。これは、問題のより単純な複製のようです。

@CharliePooleとてもいいです、確かにいくつかのSetUpFixturesがあるので、同じ問題である可能性があります。

SetUpFixtureと[assembly：Parallelizable（ParallelScope.Fixtures）]を使用するプロジェクトでも同じことが起こっています。

nunit 3.7.1では、正常に動作します。 3.8.1にアップデートしようとすると、コンソールだけでなくResharperでもテストがハングします。

@Suremakerは、断続的なコンソールランナーが消えて、ソケット例外を引き起こしていた人の1人でしたか？ ここにクロスオーバーがあるのか​​な。

@ jnm2私は現在旅行中ですが、2週間は確認できません。 残念ながら、問題を観察したときに詳細を確認しませんでしたが、12〜16回目のテストが終了した後、常に各実行でハングしていました（したがって、実行の開始時ではなく、常に指定された一定量の実行テスト）..。

さて、心配しないでください。

キューを復元するとすべてのキューが開始されたため、並列テストと非並列テストが同時に実行されていたことがわかりました。 ＃2476で修正されました。

この修正を含む新しいバージョンのリリースがいつ期待できるかを誰かが知ることができますか？

@rprouseはスケジュールに話しかける必要があります。 しかし、いずれにせよ、あなたのケースが完全にカバーされていることを確認するためにそれを試してみることができれば素晴らしいでしょう。 mygetフィードの最新の開発ビルドに変更が必要です。

こんにちは、私はビルド3.9.0-dev-04639を試しましたが、それでもうまく機能していますが、それでも時々失敗します。 コンソールランナーも一度ロックされました。

トレースログを確認した後、問題のフィクスチャがParallelizable(ParallelScope.None)マークされていても、いくつかのテストを並行して実行しているようです。

非並列フィクスチャが完了した直後に、誤った並列実行が開始されますか？ これは、非並列フィクスチャ用に新しい分離キューを作成した後でキューを復元するときです。

ここでは、各テストがどのようにマークされているかについての注釈付きのログからの抜粋が役立ちます。

数百行のスタートアップ情報を取得しています。

16:53:32.469 Debug [22] Dispatcher: Using NonParallel strategy for NonparallelFixture1
...snip...
16:53:32.469 Debug [22] Dispatcher: Using NonParallel strategy for NonparallelFixture2

..これまでのところ正しいです。

1つの非並列テストフィクスチャを実行することから始まりますが、次に並列テストの実行を開始するように見えます。

16:53:32.492 Info  [22] TestWorker: Worker#STA_NP executing NonparallelFixture1
16:53:32.492 Info  [22] Dispatcher: Saving Queue State for NonparallelFixture1
16:53:32.492 Debug [22] WorkItemQueue: NonParallelQueue.1 pausing
16:53:32.492 Info  [22] WorkItemQueue: NonParallelQueue.2 starting
16:53:32.492 Debug [22] Dispatcher: Using Direct strategy for NonparallelFixture1_Test1
16:53:32.849 Debug [22] Dispatcher: Using Direct strategy for NonparallelFixture1_Test2
16:53:32.878 Debug [22] Dispatcher: Using Direct strategy for NonparallelFixture1_Test3
16:53:32.879 Debug [22] Dispatcher: Using Direct strategy for NonparallelFixture1_Test4
16:53:32.881 Debug [22] Dispatcher: Using NonParallel strategy for NonparallelFixture1 OneTimeTearDown
16:53:32.881 Info  [22] TestWorker: Worker#STA_NP executing NonparallelFixture1 OneTimeTearDown
16:53:32.883 Info  [22] WorkShift: NonParallel shift ending
16:53:32.883 Debug [22] WorkItemQueue: NonParallelQueue.2 pausing
16:53:32.885 Info  [22] Dispatcher: Restoring Queue State
16:53:32.885 Debug [22] WorkItemQueue: ParallelQueue.2 pausing
16:53:32.886 Info  [22] WorkItemQueue: ParallelQueue.1 starting
16:53:32.886 Debug [22] WorkItemQueue: ParallelSTAQueue.2 pausing
16:53:32.886 Info  [22] WorkItemQueue: ParallelSTAQueue.1 starting
16:53:32.886 Info  [15] TestWorker: Worker#7 executing ParallelFixture1
16:53:32.886 Info  [11] TestWorker: Worker#3 executing ParallelFixture2

その後、このようになります。

16:53:32.886 Info  [22] TestWorker: Worker#STA_NP executing NonparallelFixture2
16:53:32.886 Info  [22] Dispatcher: Saving Queue State for NonparallelFixture2
16:53:32.886 Debug [22] WorkItemQueue: ParallelQueue.1 pausing
16:53:32.886 Info  [22] WorkItemQueue: ParallelQueue.2 starting
16:53:32.886 Debug [22] WorkItemQueue: ParallelSTAQueue.1 pausing
16:53:32.886 Info  [22] WorkItemQueue: ParallelSTAQueue.2 starting
16:53:32.886 Debug [22] WorkItemQueue: NonParallelQueue.1 pausing
16:53:32.886 Info  [22] WorkItemQueue: NonParallelQueue.2 starting
16:53:32.886 Debug [22] WorkItemQueue: NonParallelSTAQueue.1 pausing
16:53:32.886 Info  [22] WorkItemQueue: NonParallelSTAQueue.2 starting
16:53:32.886 Debug [20] Dispatcher: Using Direct strategy for OtherParallelTest1
16:53:32.886 Debug [18] Dispatcher: Using Direct strategy for OtherParallelTest2
16:53:32.886 Debug [10] Dispatcher: Using Direct strategy for OtherParallelTest3
...snip...
16:53:32.923 Debug [16] Dispatcher: Using Parallel strategy for ParallelFixture3 OneTimeTearDown
16:53:32.923 Info  [16] TestWorker: Worker#8 executing ParallelFixture3 OneTimeTearDown
16:53:32.926 Debug [18] Dispatcher: Using Parallel strategy for ParallelFixture4 OneTimeTearDown
16:53:32.926 Info  [16] TestWorker: Worker#8 executing ParallelFixture4 OneTimeTearDown
16:53:32.926 Debug [16] Dispatcher: Using Direct strategy for OtherParallelTest3 OneTimeTearDown
16:53:32.993 Debug [22] Dispatcher: Using Direct strategy for NonparallelFixture2_Test1
16:53:33.018 Debug [15] Dispatcher: Using Direct strategy for OtherParallelTest18
16:53:33.019 Debug [15] Dispatcher: Using Direct strategy for OtherParallelTest19
...snip...
16:53:33.051 Debug [12] Dispatcher: Using Direct strategy for OtherParallelTest35
16:53:33.053 Debug [12] Dispatcher: Using Parallel strategy for ParallelFixture5 OneTimeTearDown
16:53:33.053 Info  [16] TestWorker: Worker#8 executing ParallelFixture5 OneTimeTearDown
16:53:33.056 Debug [15] Dispatcher: Using Parallel strategy for ParallelFixture6 OneTimeTearDown
16:53:33.056 Info  [16] TestWorker: Worker#8 executing ParallelFixture6 OneTimeTearDown
16:53:33.242 Debug [22] Dispatcher: Using Direct strategy for NonparallelFixture2_Test2
16:53:33.295 Debug [22] Dispatcher: Using Direct strategy for NonparallelFixture2_Test3

.. 等々。