Nunit: NUnit 3.8+ não conclui os testes em execução

@DavidZidar Você pode adicionar detalhes de como está paralelizando seus testes? Por acessórios / casos de teste? Você tem uma mistura de itens paralelos e não paralelos?

Parece que pode estar relacionado a https://github.com/nunit/nunit/issues/2261 , que estava na versão 3.8.

Ah ... Acho que vi isso ontem executando testes via ReSharper com 3.8.0.

Estou usando [assembly: Parallelizable(ParallelScope.Fixtures)] em combinação com alguns testes que não podem ser executados em paralelo que usam o novo atributo [NonParallelizable] .

Tentei executar o runner do console com --workers = 1, mas não fez diferença.

@DavidZidar

A combinação de acessórios paralelos e itens não paralelos é fundamental. Seria muito útil se você pudesse experimentar remover alguns atributos - e ver se consegue encontrar um exemplo reproduzível mínimo.

Eu encontrei um dispositivo de teste não paralelizável que por algum motivo tinha 2x [SetUp] métodos e um [TearDown] , também tinha um [OneTimeSetUp] e um [OneTimeTearDown] . Quando eu excluí esta classe, o executor de teste CodeRush parece terminar todas as vezes, mas o executor de console ainda continua congelando na maior parte do tempo, embora agora tenha executado até a conclusão pelo menos duas vezes.

Infelizmente, não consigo reproduzir este problema em um novo projeto e este projeto é bastante grande e não posso compartilhar nenhum código.

Além disso, agora que estou executando meus testes repetidamente, alguns outros testes marcados com [NonParallelizable] falham aleatoriamente de vez em quando, como se estivessem sendo executados em paralelo, embora não devessem estar.

Tentei mais uma coisa, apaguei todos os 23 acessórios de teste com o atributo [NonParallelizable] mas isso só tornou as coisas ainda piores. Agora, o CodeRush nem passa por 10% dos testes antes de travar. Não tenho certeza de quão longe o executor do console chega. Existem cerca de 370 luminárias e 3.000 testes no total.

Eu experimentei o mesmo comportamento desde a versão 3.8.0. Após um downgrade para a versão 3.7.1. tudo funciona bem novamente. Usei o executor de teste resharper e o executor de teste do Visual Studio. Ambos tiveram o mesmo comportamento. Se eu executar todos os testes, a execução parece entrar em um deadlock. Se eu executar os testes separados, todos os testes serão executados corretamente.

Meus testes são assim. Eles simplesmente criam um userControl e verificam se o datacontext pode ser criado corretamente pelo modelo de visualização do prisma

    [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 Você está usando algum tipo de paralelismo nos testes?

No momento, acho que não deve haver paralelismo. Preciso verificar se os modelos de visão criam uma tarefa amanhã quando estou no trabalho. Se é o que você queria saber.

Eu estava me referindo ao paralelismo NUnit. O código de amostra não tem nenhum ParallelAttribute especificado, mas pode estar presente em um nível superior, como um atributo de montagem, por exemplo.

Não, eu não usei ParallelAttribute . Desculpe, eu sou novo no nUnit e não tinha conhecimento desse atributo.

@Maradaehne Você está

Parece-me que o seu problema está relacionado ao uso do STA ou o seu TestBootstrapper está fazendo algo que o causa. Qual é o propósito dessa ligação? Por que você deseja que ele seja executado várias vezes? Ele continua a funcionar? (Nesse caso, você precisa encerrá-lo)

WRT o STA, crie um pequeno teste que verifica se ele está realmente em execução no STA, conforme solicitado no aparelho. Provavelmente é, ausência de execução paralela, mas vamos ter certeza.

Olá, só para começar, pois nossos testes também começaram a pendurar com o NUnit 3.8+, também estamos usando [assembly: Parallelizable (ParallelScope.Fixtures)]. Ainda não experimentamos o atributo NonParallelizable.

Terei que explorar os métodos de configuração e desmontagem usados ​​para ver se isso ajuda. Existe alguma herança de teste em jogo, por isso é um pouco confuso.

Espero que isso também seja corrigido por https://github.com/nunit/nunit/pull/2445

Se alguém puder testar a correção - ela pode ser baixada do Appveyor aqui: https://ci.appveyor.com/project/CharliePoole/nunit/build/3.9.0-ci-04450-issue-2438/artifacts

Acabei de testar a compilação 3.9.0-ci-04450-issue-2438 e, embora pareça ter melhorado bastante as coisas, ainda não está lá.

O executor de teste do CodeRush parece concluir todas as vezes agora, então isso é bom, mas alguns de nossos testes com o atributo Parallelizable(ParallelScope.None) ainda falham aleatoriamente e esses testes têm funcionado bem por meses usando o NUnit 3.5.0.

O corredor do console ainda trava de vez em quando.

Obrigado @DavidZidar. @rprouse encontrou alguns problemas adicionais com esse PR, acho que temos mais para analisar.

Como antes - se você for capaz de descobrir quaisquer exemplos reproduzíveis, isso seria inestimável. Corrigimos o problema conforme ele se manifestava em https://github.com/nunit/nunit/issues/2438 - mas parece que seu conjunto de testes maior pode estar atingindo diferentes cenários.

Também estou intrigado com seus testes não paralelos sendo executados em paralelo. Você pode produzir alguns logs, usando --trace=Verbose . Você pode anonimizar conforme necessário, mas isso deve nos dar uma visão do que está acontecendo se seus testes não paralelos estiverem sendo executados em paralelo. (Inclua também quais testes não devem ser paralelos, o que pode não estar claro nos registros!)

Edit: Por favor, faça isso contra a compilação 3.9.0-ci - que esperançosamente está se movendo na direção certa.

Desculpe não ter sido claro, algumas afirmações estão falhando aleatoriamente em alguns dos meus testes que realmente não deveriam estar falhando, a menos que estejam sendo executados em paralelo e alguns testes lançem NullReferenceException quando realmente não deveriam.

Por exemplo, alguns de nossos testes precisam configurar DependencyResolver.Current do MVC e um desses testes às vezes falha com NullReferenceException quando está usando o resolvedor como se tivesse sido definido como nulo ou reconfigurado com serviços diferentes para algum outro teste.

Uma pergunta, os testes marcados com Parallelizable(ParallelScope.None) garantem ser o único teste atualmente em execução por processo? Porque parece que talvez algum outro método de configuração ou desmontagem tenha sido invocado entre a configuração e a execução deste teste específico.

Obrigado por esclarecer. 🙂

Uma pergunta: os testes marcados com Parallelizable (ParallelScope.None) são os únicos testes atualmente em execução por processo? Porque parece que talvez algum outro método de configuração ou desmontagem tenha sido invocado entre a configuração e a execução deste teste específico.

Essa é a teoria, sim. Parece que pode haver alguns problemas com isso no 3.8, no entanto, com as alterações para permitir que os casos de teste sejam executados em paralelo.

Duas coisas:
1) Você pode esclarecer como está usando Parallelizable(ParallelScope.None) - é em instalações de teste ou testes individuais?
2) Como acima - deve ser possível olhar para um arquivo de log e verificar se os testes executados incorretamente em paralelo é definitivamente o seu problema. (Parece muito provável, mas seria bom verificar antes de aprofundarmos!)

Estamos usando o atributo apenas em luminárias, não em testes individuais

Aqui está um único nó de suíte de teste anônimo de um teste com uma afirmação com falha que realmente não deve falhar.

              <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>

Curiosamente, o tempo de início e término é o mesmo em todos eles, embora eu não tenha certeza se isso significa alguma coisa. O NUnit 3.5 parece se comportar da mesma forma.

Desculpe, não acho que fui claro com meu comentário de log.

Passe o argumento --trace=Verbose na linha de comando do console NUnit. Isso criará vários arquivos .log - um deles detalha quais testes foram executados em quais threads de trabalho, em qual ordem e como foram paralelizados. O número entre colchetes está relacionado ao número do trabalhador - veja o exemplo abaixo:

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)

A partir deste arquivo, você deve ser capaz de ver se os testes que você espera que não sejam paralelos, estão sendo executados em paralelo com outros testes ou não.

Oh, certo. Não vi os arquivos de log a princípio.

Aqui está um fragmento anônimo, o teste com falha estava sendo executado no thread 22 e parece estar usando "Estratégia direta" para todos os testes neste equipamento específico, embora o equipamento esteja marcado com 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

Se isso não for suficiente, talvez eu possa enviar a você por e-mail o arquivo de log bruto em particular.

A estratégia direta é correta para testes sem um atributo. Significa apenas executar no mesmo encadeamento, sem criar uma nova entrada na fila.

Presumo que os outros testes intercalados com o thread 22 sejam testes paralelos no mesmo dispositivo.

Ah, eu entendi.

Não, os testes nas outras roscas são de outros acessórios.

Então, precisamos descobrir por que eles estão funcionando. Se o aparelho não for paralelizável, nenhum outro deve estar funcionando ao mesmo tempo.

Experimentar...

1. Usando NonParallelizable em vez de ParallelScope.None. Deve ser o mesmo, mas um bug é possível.

2. Liste para nós todos os atributos paralelos no acessório e as suítes que o contêm até a montagem.

1. Tentei, não fez diferença, pelo que posso dizer
2. AssemblyInfo.cs tem [assembly: Parallelizable(ParallelScope.Fixtures)] e agora alguns acessórios têm o atributo NonParallelizable, é isso

Isso reduz o problema. Seu aparelho não paralelo está funcionando em paralelo com algum outro aparelho ou aparelhos. O enforcamento é um efeito secundário.

Idealmente, seria bom se você pudesse verificar o acima, executando o 3.7.1 e examinando a saída de --trace:Verbose . Você deve ver apenas os testes de um único aparelho não paralelo rodando junto.

Se for esse o caso, podemos examinar a seguir se os aparelhos rodando erroneamente em paralelo com o aparelho NP têm algo em comum ou se é um problema mais geral no despachante.

Certo, tentei rodar com 3.7.1 e ele executa nossos testes muito bem todas as vezes. A diferença que estou vendo é que o 3.7.1 parece estar executando todos os testes não paralelizáveis ​​em série em um único thread no final, ao contrário do 3.8+, que parece executá-los sempre.

Em uma situação simples como essa (a maioria dos aparelhos em paralelo com alguns casos de teste não paralelos e sem paralelizabilidade) é o que deve acontecer. Todos os acessórios paralelizáveis ​​devem ser concluídos, em seguida, os não paralelizáveis.

@ChrisMaddock Esta parece ser a chave para mim. Fizemos algumas correções para os casos de canto, mas parece que bagunçamos um caso muito simples.

@DavidZidar Veja a edição nº 2454, que parece uma replicação mais simples do seu problema.

@CharliePoole Muito bom, realmente temos alguns SetUpFixtures, então parece que pode ser o mesmo problema.

O mesmo está acontecendo em nosso projeto onde usamos SetUpFixture e [assembly: Parallelizable (ParallelScope.Fixtures)].

Na nunit 3.7.1 funciona bem. Quando tentei atualizar para 3.8.1, os testes travaram no Resharper e também no console.

@Suremaker você era uma das pessoas que estava correndo para o corredor do console intermitente, desaparecendo e causando uma exceção de soquete? Eu me pergunto se há crossover aqui.

@ jnm2 Atualmente estou viajando e há 2 semanas não poderei conferir. Infelizmente, não verifiquei os detalhes quando observei o problema, no entanto, ele estava sempre pendurado em cada execução, após cerca de 12 a 16 teste concluído (portanto, não no início da execução, mas sempre após uma quantidade constante e especificada de os testes de execução) ...

Ok, não se preocupe com isso.

Acontece que a restauração das filas estava iniciando todas as filas, de modo que testes paralelos e não paralelos estavam sendo executados ao mesmo tempo. Corrigido em # 2476.

Alguém é capaz de dizer quando poderíamos esperar o lançamento de uma nova versão contendo essa correção?

@rprouse terá que falar com a programação. Mas, em qualquer caso, seria ótimo se você pudesse experimentar para ter certeza de que seu caso foi totalmente coberto. A última compilação de desenvolvimento em nosso feed myget deve ter a alteração.

Olá, acabei de tentar compilar 3.9.0-dev-04639 e, embora funcione ainda melhor, ainda falha de vez em quando. O runner do console também travou uma vez.

Depois de verificar os logs de rastreamento, ele ainda parece estar executando alguns testes em paralelo, embora os fixtures em questão estejam marcados com Parallelizable(ParallelScope.None) .

A execução paralela incorreta começa imediatamente após a conclusão de um acessório não paralelo? É quando restauramos as filas depois de criar novas filas isoladas para o dispositivo não paralelo.

Um trecho do seu registro com anotações sobre como cada teste é marcado seria útil aqui.

Estou recebendo algumas centenas de linhas de informações de inicialização, e entre elas ..

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

.. o que está correto até agora.

Parece que começa executando um dispositivo de teste não paralelo, mas depois começa a executar testes paralelos.

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

Então, mais tarde, fica assim ..

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

.. e assim por diante.