Eseguire unit test in serie (anziché in parallelo)

Sto tentando di testare l'unità di un motore di gestione host WCF che ho scritto. Il motore fondamentalmente crea istanze ServiceHost al volo in base alla configurazione. Questo ci consente di riconfigurare dinamicamente quali servizi sono disponibili senza doverli disattivare tutti e riavviarli ogni volta che viene aggiunto un nuovo servizio o viene rimosso uno vecchio.

Tuttavia, ho riscontrato difficoltà nel testare l'unità di questo motore di gestione host, a causa del modo in cui funziona ServiceHost. Se un ServiceHost è già stato creato, aperto e non ancora chiuso per un particolare endpoint, non è possibile creare un altro ServiceHost per lo stesso endpoint, con conseguente eccezione. A causa del fatto che le moderne piattaforme di unit test parallelizzano la loro esecuzione dei test, non ho un modo efficace per unit test di questo pezzo di codice.

Ho usato xUnit.NET, sperando che a causa della sua estensibilità, avrei potuto trovare un modo per costringerlo a eseguire i test in serie. Tuttavia, non ho avuto fortuna. Spero che qualcuno qui su SO abbia riscontrato un problema simile e sappia come eseguire i test unitari in serie.

NOTA: ServiceHost è una classe WCF, scritta da Microsoft. Non ho la capacità di cambiare il suo comportamento. Anche l'hosting di ciascun endpoint del servizio una sola volta è il comportamento corretto ... tuttavia, non è particolarmente favorevole ai test di unità.

Ogni classe di test è una raccolta di test univoca e i test sotto di essa verranno eseguiti in sequenza, quindi se metti tutti i tuoi test nella stessa raccolta, verranno eseguiti in sequenza.

In xUnit puoi apportare le seguenti modifiche per ottenere ciò:

Di seguito verrà eseguito in parallelo:

namespace IntegrationTests
{
    public class Class1
    {
        [Fact]
        public void Test1()
        {
            Console.WriteLine("Test1 called");
        }

        [Fact]
        public void Test2()
        {
            Console.WriteLine("Test2 called");
        }
    }

    public class Class2
    {
        [Fact]
        public void Test3()
        {
            Console.WriteLine("Test3 called");
        }

        [Fact]
        public void Test4()
        {
            Console.WriteLine("Test4 called");
        }
    }
}

Per renderlo sequenziale devi solo mettere entrambe le classi di test nella stessa raccolta:

namespace IntegrationTests
{
    [Collection("Sequential")]
    public class Class1
    {
        [Fact]
        public void Test1()
        {
            Console.WriteLine("Test1 called");
        }

        [Fact]
        public void Test2()
        {
            Console.WriteLine("Test2 called");
        }
    }

    [Collection("Sequential")]
    public class Class2
    {
        [Fact]
        public void Test3()
        {
            Console.WriteLine("Test3 called");
        }

        [Fact]
        public void Test4()
        {
            Console.WriteLine("Test4 called");
        }
    }
}

Per maggiori info puoi fare riferimento a questo link

Come affermato sopra, tutti i buoni unit test dovrebbero essere isolati al 100%. L'utilizzo dello stato condiviso (ad esempio, a seconda di una staticproprietà che viene modificata da ciascun test) è considerato una cattiva pratica.

Detto questo, la tua domanda sull'esecuzione dei test xUnit in sequenza ha una risposta! Ho riscontrato esattamente lo stesso problema perché il mio sistema utilizza un localizzatore di servizi statici (che è tutt'altro che ideale).

Per impostazione predefinita, xUnit 2.x esegue tutti i test in parallelo. Questo può essere modificato per assembly definendo il file CollectionBehaviorin AssemblyInfo.cs nel progetto di test.

Per la separazione per assemblaggio utilizzare:

using Xunit;
[assembly: CollectionBehavior(CollectionBehavior.CollectionPerAssembly)]

o per nessuna parallelizzazione utilizzare:

[assembly: CollectionBehavior(DisableTestParallelization = true)]

Quest'ultimo è probabilmente quello che desideri. Ulteriori informazioni sulla parallelizzazione e la configurazione sono disponibili nella documentazione di xUnit .

Per i progetti .NET Core, crea xunit.runner.jsoncon:

{
  "parallelizeAssembly": false,
  "parallelizeTestCollections": false
}

Inoltre, il tuo csprojdovrebbe contenere

<ItemGroup>
  <None Update="xunit.runner.json"> 
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  </None>
</ItemGroup>

Per i vecchi progetti .Net Core, project.jsondovresti contenere

"buildOptions": {
  "copyToOutput": {
    "include": [ "xunit.runner.json" ]
  }
}

Per i progetti .NET Core, puoi configurare xUnit con un xunit.runner.jsonfile, come documentato su https://xunit.github.io/docs/configuring-with-json.html .

L'impostazione che è necessario modificare per interrompere l'esecuzione del test parallelo è parallelizeTestCollections, che per impostazione predefinita è true:

Impostalo su truese l'assembly è disposto a eseguire test all'interno di questo assembly in parallelo l'uno contro l'altro. ... Impostalo su falseper disabilitare tutta la parallelizzazione all'interno di questo assembly di test.

Tipo di schema JSON: booleano
Valore predefinito:true

Quindi xunit.runner.jsonsembra un minimo per questo scopo

{
    "parallelizeTestCollections": false
}

Come indicato nella documentazione, ricorda di includere questo file nella tua build, in uno dei seguenti modi:

• Impostazione di Copia nella directory di output su Copia se più recente nelle Proprietà del file in Visual Studio o

• Aggiunta

  <Content Include=".\xunit.runner.json">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
  </Content>

  al tuo .csprojfile, o

• Aggiunta

  "buildOptions": {
    "copyToOutput": {
      "include": [ "xunit.runner.json" ]
    }
  }

  al tuo project.jsonfile

a seconda del tipo di progetto.

Infine, oltre a quanto sopra, se stai usando Visual Studio, assicurati di non aver fatto clic accidentalmente sul pulsante Esegui test in parallelo , il che farà sì che i test vengano eseguiti in parallelo anche se hai disattivato la parallelizzazione in xunit.runner.json. I progettisti dell'interfaccia utente di Microsoft hanno abilmente reso questo pulsante senza etichetta, difficile da notare e distante circa un centimetro dal pulsante "Esegui tutto" in Esplora test, solo per massimizzare la possibilità che tu lo prema per errore e non hai idea del perché i tuoi test stanno improvvisamente fallendo:

Questa è una vecchia domanda ma volevo scrivere una soluzione per le persone che cercano di recente come me :)

Nota: utilizzo questo metodo nei test di integrazione Dot Net Core WebUI con xunit versione 2.4.1.

Creare una classe vuota denominata NonParallelCollectionDefinitionClass e quindi assegnare l'attributo CollectionDefinition a questa classe come di seguito. (La parte importante è DisableParallelization = true setting.)

using Xunit;

namespace WebUI.IntegrationTests.Common
{
    [CollectionDefinition("Non-Parallel Collection", DisableParallelization = true)]
    public class NonParallelCollectionDefinitionClass
    {
    }
}

Quindi aggiungi l'attributo Collection alla classe che non vuoi che venga eseguita in parallelo come di seguito. (La parte importante è il nome della raccolta. Deve essere lo stesso del nome utilizzato in CollectionDefinition)

namespace WebUI.IntegrationTests.Controllers.Users
{
    [Collection("Non-Parallel Collection")]
    public class ChangePassword : IClassFixture<CustomWebApplicationFactory<Startup>>
    ...

Quando lo facciamo, in primo luogo vengono eseguiti altri test paralleli. Successivamente vengono eseguiti gli altri test che hanno l'attributo Collection ("Non-Parallel Collection").

puoi usare la playlist

fare clic con il tasto destro sul metodo di prova -> Aggiungi a playlist -> Nuova playlist

quindi puoi specificare l'ordine di esecuzione, l'impostazione predefinita è, quando li aggiungi alla playlist ma puoi cambiare il file della playlist come vuoi

Non conosco i dettagli, ma sembra che tu stia cercando di fare test di integrazione piuttosto che test di unità . Se potessi isolare la dipendenza da ServiceHost, questo probabilmente renderebbe il tuo test più facile (e veloce). Quindi (ad esempio) potresti testare quanto segue in modo indipendente:

• Classe di lettura della configurazione
• ServiceHost factory (possibilmente come test di integrazione)
• Classe del motore che richiede un IServiceHostFactorye unIConfiguration

Strumenti che potrebbero aiutare a includere framework di isolamento (mocking) e (facoltativamente) framework di contenitori IoC. Vedere:

• http://www.mockobjects.com/
• http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx

Forse puoi usare Advanced Unit Testing . Ti consente di definire la sequenza in cui eseguire il test . Quindi potrebbe essere necessario creare un nuovo file cs per ospitare quei test.

Ecco come puoi piegare i metodi di prova per lavorare nella sequenza che desideri.

[Test]
[Sequence(16)]
[Requires("POConstructor")]
[Requires("WorkOrderConstructor")]
public void ClosePO()
{
  po.Close();

  // one charge slip should be added to both work orders

  Assertion.Assert(wo1.ChargeSlipCount==1,
    "First work order: ChargeSlipCount not 1.");
  Assertion.Assert(wo2.ChargeSlipCount==1,
    "Second work order: ChargeSlipCount not 1.");
  ...
}

Fammi sapere se funziona.

Per me, nell'applicazione .Net Core Console, quando volevo eseguire metodi di test (non classi) in modo sincrono, l'unica soluzione che ha funzionato era questa descritta in questo blog: xUnit: Control the Test Execution Order

Ho aggiunto l'attributo [Collection ("Sequential")] in una classe base:

    namespace IntegrationTests
    {
      [Collection("Sequential")]
      public class SequentialTest : IDisposable
      ...


      public class TestClass1 : SequentialTest
      {
      ...
      }

      public class TestClass2 : SequentialTest
      {
      ...
      }
    }

Nessuna delle risposte suggerite finora ha funzionato per me. Ho un'app dotnet core con XUnit 2.4.1. Ho ottenuto il comportamento desiderato con una soluzione alternativa inserendo un blocco in ogni unit test. Nel mio caso, non mi importava dell'ordine di esecuzione, solo che i test erano sequenziali.

public class TestClass
{
    [Fact]
    void Test1()
    {
        lock (this)
        {
            //Test Code
        }
    }

    [Fact]
    void Test2()
    {
        lock (this)
        {
            //Test Code
        }
    }
}