Exécuter des tests unitaires en série (plutôt qu'en parallèle)

J'essaye de tester unitaire un moteur de gestion d'hôte WCF que j'ai écrit. Le moteur crée essentiellement des instances ServiceHost à la volée en fonction de la configuration. Cela nous permet de reconfigurer dynamiquement les services disponibles sans avoir à tous les arrêter et à les redémarrer chaque fois qu'un nouveau service est ajouté ou un ancien est supprimé.

Cependant, j'ai rencontré une difficulté lors des tests unitaires de ce moteur de gestion d'hôte en raison du fonctionnement de ServiceHost. Si un ServiceHost a déjà été créé, ouvert et pas encore fermé pour un point de terminaison particulier, un autre ServiceHost pour le même point de terminaison ne peut pas être créé, ce qui entraîne une exception. En raison du fait que les plates-formes de test unitaire modernes parallélisent leur exécution de test, je n'ai aucun moyen efficace de tester unité ce morceau de code.

J'ai utilisé xUnit.NET, en espérant qu'en raison de son extensibilité, je pourrais trouver un moyen de le forcer à exécuter les tests en série. Cependant, je n'ai pas eu de chance. J'espère que quelqu'un ici sur SO a rencontré un problème similaire et sait comment faire exécuter des tests unitaires en série.

REMARQUE: ServiceHost est une classe WCF, écrite par Microsoft. Je n'ai pas la capacité de changer son comportement. Héberger chaque point de terminaison de service une seule fois est également le bon comportement ... cependant, ce n'est pas particulièrement propice aux tests unitaires.

Chaque classe de test est une collection de tests unique et les tests sous-jacents seront exécutés en séquence, donc si vous placez tous vos tests dans la même collection, elle s'exécutera séquentiellement.

Dans xUnit, vous pouvez apporter les modifications suivantes pour y parvenir:

Ce qui suit fonctionnera en parallèle:

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");
        }
    }
}

Pour le rendre séquentiel, il vous suffit de placer les deux classes de test sous la même collection:

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");
        }
    }
}

Pour plus d'informations, vous pouvez vous référer à ce lien

Comme indiqué ci-dessus, tous les bons tests unitaires doivent être isolés à 100%. L'utilisation de l'état partagé (par exemple en fonction d'une staticpropriété modifiée par chaque test) est considérée comme une mauvaise pratique.

Cela dit, votre question sur l'exécution des tests xUnit en séquence a une réponse! J'ai rencontré exactement le même problème car mon système utilise un localisateur de service statique (ce qui est loin d'être idéal).

Par défaut, xUnit 2.x exécute tous les tests en parallèle. Cela peut être modifié par assemblage en définissant le CollectionBehaviordans votre AssemblyInfo.cs dans votre projet de test.

Pour la séparation par assemblage, utilisez:

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

ou pour aucune parallélisation, utilisez:

[assembly: CollectionBehavior(DisableTestParallelization = true)]

Ce dernier est probablement celui que vous souhaitez. Vous trouverez plus d'informations sur la parallélisation et la configuration dans la documentation de xUnit .

Pour les projets .NET Core, créez xunit.runner.jsonavec:

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

En outre, votre csprojdevrait contenir

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

Pour les anciens projets .Net Core, votre project.jsondevrait contenir

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

Pour les projets .NET Core, vous pouvez configurer xUnit avec un xunit.runner.jsonfichier, comme indiqué sur https://xunit.github.io/docs/configuring-with-json.html .

Le paramètre que vous devez modifier pour arrêter l'exécution des tests parallèles est parallelizeTestCollections, par défaut true:

Définissez ceci sur truesi l'assembly est prêt à exécuter des tests à l'intérieur de cet assembly en parallèle les uns par rapport aux autres. ... Définissez cette option sur falsepour désactiver toute la parallélisation dans cet assemblage de test.

Type de schéma JSON: booléen
Valeur par défaut:true

Donc, un minimum xunit.runner.jsonà cet effet ressemble à

{
    "parallelizeTestCollections": false
}

Comme indiqué dans la documentation, n'oubliez pas d'inclure ce fichier dans votre build, soit en:

• Définition de Copier dans le répertoire de sortie sur Copier si plus récent dans les propriétés du fichier dans Visual Studio, ou

• Ajouter

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

  à votre .csprojdossier, ou

• Ajouter

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

  à votre project.jsondossier

en fonction de votre type de projet.

Enfin, en plus de ce qui précède, si vous utilisez Visual Studio, assurez-vous que vous n'avez pas accidentellement cliqué sur le bouton Exécuter les tests en parallèle , ce qui entraînera l'exécution des tests en parallèle même si vous avez désactivé la parallélisation dans xunit.runner.json. Les concepteurs d'interface utilisateur de Microsoft ont astucieusement rendu ce bouton sans étiquette, difficile à remarquer et à environ un centimètre du bouton "Tout exécuter" dans l'Explorateur de tests, juste pour maximiser les chances que vous le frappiez par erreur et que vous ne sachiez pas pourquoi vos tests échouent soudainement:

C'est une vieille question mais je voulais écrire une solution aux personnes qui recherchent nouvellement comme moi :)

Remarque: j'utilise cette méthode dans les tests d'intégration Dot Net Core WebUI avec xunit version 2.4.1.

Créez une classe vide nommée NonParallelCollectionDefinitionClass, puis attribuez l'attribut CollectionDefinition à cette classe comme ci-dessous. (La partie importante est DisableParallelization = true setting.)

using Xunit;

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

Ensuite, ajoutez l'attribut Collection à la classe que vous ne voulez pas qu'il exécute en parallèle comme ci-dessous. (La partie importante est le nom de la collection. Il doit être identique au nom utilisé dans CollectionDefinition)

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

Lorsque nous faisons cela, tout d'abord d'autres tests parallèles sont exécutés. Après cela, les autres tests qui ont l'attribut Collection ("Non-Parallel Collection") s'exécutent.

vous pouvez utiliser la liste de lecture

clic droit sur la méthode de test -> Ajouter à la playlist -> Nouvelle playlist

alors vous pouvez spécifier l'ordre d'exécution, la valeur par défaut est, lorsque vous les ajoutez à la liste de lecture, mais vous pouvez changer le fichier de liste de lecture comme vous le souhaitez

Je ne connais pas les détails, mais il semble que vous essayez de faire des tests d'intégration plutôt que des tests unitaires . Si vous pouviez isoler la dépendance sur ServiceHost, cela rendrait probablement vos tests plus faciles (et plus rapides). Ainsi (par exemple) vous pouvez tester les éléments suivants indépendamment:

• Classe de lecture de configuration
• ServiceHost factory (éventuellement comme test d'intégration)
• Classe de moteur qui prend un IServiceHostFactoryet unIConfiguration

Des outils qui aideraient à inclure des frameworks d'isolation (mocking) et (éventuellement) des frameworks de conteneurs IoC. Voir:

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

Vous pouvez peut-être utiliser Advanced Unit Testing . Il vous permet de définir la séquence dans laquelle vous exécutez le test . Vous devrez peut-être créer un nouveau fichier cs pour héberger ces tests.

Voici comment plier les méthodes de test pour qu'elles fonctionnent dans l'ordre souhaité.

[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.");
  ...
}

Faites-moi savoir si cela fonctionne.

Pour moi, dans l'application .Net Core Console, lorsque je voulais exécuter des méthodes de test (pas des classes) de manière synchrone, la seule solution qui fonctionnait était celle décrite dans ce blog: xUnit: contrôler l'ordre d'exécution des tests

J'ai ajouté l'attribut [Collection ("Sequential")] dans une classe de base:

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


      public class TestClass1 : SequentialTest
      {
      ...
      }

      public class TestClass2 : SequentialTest
      {
      ...
      }
    }

Aucune des réponses suggérées jusqu'à présent n'a fonctionné pour moi. J'ai une application de base dotnet avec XUnit 2.4.1. J'ai obtenu le comportement souhaité avec une solution de contournement en plaçant un verrou dans chaque test unitaire à la place. Dans mon cas, je ne me souciais pas de l'ordre de marche, juste que les tests étaient séquentiels.

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

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