Unit-Tests seriell (statt parallel) ausführen

Ich versuche, eine von mir geschriebene WCF-Host-Management-Engine zu testen. Die Engine erstellt ServiceHost-Instanzen grundsätzlich im laufenden Betrieb basierend auf der Konfiguration. Auf diese Weise können wir dynamisch neu konfigurieren, welche Dienste verfügbar sind, ohne alle herunterfahren und neu starten zu müssen, wenn ein neuer Dienst hinzugefügt oder ein alter entfernt wird.

Ich habe jedoch aufgrund der Funktionsweise von ServiceHost Schwierigkeiten beim Testen dieser Host-Management-Engine. Wenn für einen bestimmten Endpunkt bereits ein ServiceHost erstellt, geöffnet und noch nicht geschlossen wurde, kann kein anderer ServiceHost für denselben Endpunkt erstellt werden, was zu einer Ausnahme führt. Aufgrund der Tatsache, dass moderne Unit-Test-Plattformen ihre Testausführung parallelisieren, habe ich keine effektive Möglichkeit, diesen Code zu testen.

Ich habe xUnit.NET verwendet, in der Hoffnung, dass ich aufgrund seiner Erweiterbarkeit einen Weg finden könnte, es zu zwingen, die Tests seriell auszuführen. Ich hatte jedoch kein Glück. Ich hoffe, dass jemand hier auf SO auf ein ähnliches Problem gestoßen ist und weiß, wie Unit-Tests seriell ausgeführt werden können.

HINWEIS: ServiceHost ist eine WCF-Klasse, die von Microsoft geschrieben wurde. Ich habe nicht die Fähigkeit, sein Verhalten zu ändern. Das einmalige Hosten jedes Service-Endpunkts ist ebenfalls das richtige Verhalten. Es ist jedoch für Unit-Tests nicht besonders förderlich.

Jede Testklasse ist eine eindeutige Testsammlung, und die Tests darunter werden nacheinander ausgeführt. Wenn Sie also alle Ihre Tests in derselben Sammlung ablegen, wird sie nacheinander ausgeführt.

In xUnit können Sie folgende Änderungen vornehmen, um dies zu erreichen:

Folgendes läuft parallel:

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

Um es sequentiell zu machen, müssen Sie nur beide Testklassen unter dieselbe Sammlung stellen:

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

Weitere Informationen finden Sie unter diesem Link

Wie oben angegeben, sollten alle guten Unit-Tests zu 100% isoliert sein. Die Verwendung eines gemeinsam genutzten Status (z. B. abhängig von einer staticEigenschaft, die von jedem Test geändert wird) wird als schlechte Praxis angesehen.

Allerdings hat Ihre Frage zum Ausführen von xUnit-Tests nacheinander eine Antwort! Ich habe genau das gleiche Problem festgestellt, weil mein System einen statischen Service-Locator verwendet (der nicht ideal ist).

Standardmäßig führt xUnit 2.x alle Tests parallel aus. Dies kann pro Baugruppe geändert werden, indem Sie die CollectionBehaviorin Ihrer AssemblyInfo.cs in Ihrem Testprojekt definieren.

Für die Trennung pro Baugruppe verwenden:

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

oder für überhaupt keine Parallelisierung verwenden:

[assembly: CollectionBehavior(DisableTestParallelization = true)]

Letzteres ist wahrscheinlich das, was Sie wollen. Weitere Informationen zur Parallelisierung und Konfiguration finden Sie in der xUnit-Dokumentation .

Erstellen Sie für .NET Core-Projekte Folgendes xunit.runner.json:

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

Auch sollte Ihr csprojenthalten

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

Für alte .Net Core-Projekte sollte Ihr project.jsonenthalten

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

Für .NET Core-Projekte können Sie xUnit mit einer xunit.runner.jsonDatei konfigurieren , wie unter https://xunit.github.io/docs/configuring-with-json.html dokumentiert .

Die Einstellung, die Sie ändern müssen, um die parallele Testausführung zu stoppen, lautet parallelizeTestCollectionsstandardmäßig true:

Stellen Sie dies ein, truewenn die Assembly bereit ist, Tests innerhalb dieser Assembly parallel gegeneinander auszuführen. ... Setzen Sie dies auf false, um die gesamte Parallelisierung innerhalb dieser Testbaugruppe zu deaktivieren.

JSON-Schematyp: boolean
Standardwert:true

So xunit.runner.jsonsieht ein Minimum für diesen Zweck aus

{
    "parallelizeTestCollections": false
}

Denken Sie daran, diese Datei, wie in den Dokumenten angegeben, in Ihren Build aufzunehmen, entweder durch:

• Festlegen von " Kopieren in Ausgabeverzeichnis" auf " Kopieren", falls in den Eigenschaften der Datei in Visual Studio oder neu

• Hinzufügen

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

  zu Ihrer .csprojDatei, oder

• Hinzufügen

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

  zu Ihrer project.jsonDatei

abhängig von Ihrem Projekttyp.

Schließlich zusätzlich zu den oben genannten, wenn Sie Visual Studio dann verwenden stellen Sie sicher , dass Sie nicht versehentlich die geklickt haben , Run Tests Parallel - Taste, die Tests werden dazu führen , parallel laufen zu lassen , auch wenn Sie aus Parallelisierung in aktiviert haben xunit.runner.json. Die UI-Designer von Microsoft haben diese Schaltfläche schlau unbeschriftet, schwer zu bemerken und etwa einen Zentimeter von der Schaltfläche "Alle ausführen " im Test-Explorer entfernt, um die Wahrscheinlichkeit zu maximieren, dass Sie sie versehentlich treffen und keine Ahnung haben, warum Ihre Tests durchgeführt wurden scheitern plötzlich:

Dies ist eine alte Frage, aber ich wollte eine Lösung für Leute schreiben, die wie ich neu suchen :)

Hinweis: Ich verwende diese Methode in Dot Net Core WebUI-Integrationstests mit xunit Version 2.4.1.

Erstellen Sie eine leere Klasse mit dem Namen NonParallelCollectionDefinitionClass und geben Sie dieser Klasse das CollectionDefinition-Attribut wie folgt. (Der wichtige Teil ist DisableParallelization = true-Einstellung.)

using Xunit;

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

Fügen Sie anschließend der Klasse das Collection-Attribut hinzu, das nicht wie unten gezeigt parallel ausgeführt werden soll. (Der wichtige Teil ist der Name der Sammlung. Er muss mit dem in CollectionDefinition verwendeten Namen identisch sein.)

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

Wenn wir dies tun, werden zunächst andere parallele Tests ausgeführt. Danach werden die anderen Tests mit dem Attribut "Sammlung" ("Nicht parallele Sammlung") ausgeführt.

Sie können die Wiedergabeliste verwenden

Klicken Sie mit der rechten Maustaste auf die Testmethode -> Zur Wiedergabeliste hinzufügen -> Neue Wiedergabeliste

Anschließend können Sie die Ausführungsreihenfolge angeben. Die Standardeinstellung ist, wenn Sie sie zur Wiedergabeliste hinzufügen. Sie können die Wiedergabelistendatei jedoch beliebig ändern

Ich kenne die Details nicht, aber es scheint, als würden Sie eher versuchen, Integrationstests als Unit-Tests durchzuführen . Wenn Sie die Abhängigkeit von isolieren könnten ServiceHost, würde dies Ihre Tests wahrscheinlich einfacher (und schneller) machen. So können Sie (zum Beispiel) Folgendes unabhängig voneinander testen:

• Konfigurationsleseklasse
• ServiceHost-Fabrik (möglicherweise als Integrationstest)
• Motorklasse, die ein IServiceHostFactoryund ein nimmtIConfiguration

Zu den Tools, die helfen würden, gehören Isolations- (Verspottungs-) Frameworks und (optional) IoC-Container-Frameworks. Sehen:

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

Möglicherweise können Sie Advanced Unit Testing verwenden . Hier können Sie die Reihenfolge definieren, in der Sie den Test ausführen . Daher müssen Sie möglicherweise eine neue CS-Datei erstellen, um diese Tests zu hosten.

Hier erfahren Sie, wie Sie die Testmethoden so biegen können, dass sie in der gewünschten Reihenfolge funktionieren.

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

Lassen Sie mich wissen, ob es funktioniert.

Wenn ich in der .Net Core Console-Anwendung Testmethoden (keine Klassen) synchron ausführen wollte, war die einzige Lösung, die funktionierte, die in diesem Blog beschriebene: xUnit: Steuern der Testausführungsreihenfolge

Ich habe das Attribut [Collection ("Sequential")] in einer Basisklasse hinzugefügt :

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


      public class TestClass1 : SequentialTest
      {
      ...
      }

      public class TestClass2 : SequentialTest
      {
      ...
      }
    }

Keine der vorgeschlagenen Antworten hat bisher für mich funktioniert. Ich habe eine Dotnet Core App mit XUnit 2.4.1. Ich habe das gewünschte Verhalten mit einer Problemumgehung erreicht, indem ich stattdessen in jedem Komponententest eine Sperre gesetzt habe. In meinem Fall war mir die laufende Reihenfolge egal, nur dass die Tests sequentiell waren.

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

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