Live Unit Testing – FAQ (Häufig gestellte Fragen)

Live Unit Testing kann mit den drei gängigen Frameworks für Komponententests verwendet werden, die in der folgenden Tabelle aufgeführt sind. Die unterstützte Mindestversion der Adapter und Frameworks ist ebenfalls in der Tabelle aufgeführt. Die Frameworks für Komponententests sind auf „NuGet.org“ verfügbar.

Wenn Sie ältere auf MSTest-basierende Testprojekte haben, die sich auf Microsoft.VisualStudio.QualityTools.UnitTestFramework beziehen, und Sie nicht auf die neueren MSTest-NuGet-Pakete umsteigen möchten, sollten Sie auf Visual Studio 2019 oder Visual Studio 2017 upgraden.

Ja. Live Unit Testing funktioniert mit .NET Core und .NET Frameworks.

Eine Meldung im Ausgabefenster (wenn das Live Unit Testing-Dropdownmenü ausgewählt ist) sollte Ihnen mitteilen, warum Live Unit Testing nicht funktioniert. Live Unit Testing funktioniert möglicherweise aus einem der folgenden Gründe nicht:

• Wenn die NuGet-Pakete, auf die von Projekten in der Projektmappe verwiesen wird, nicht wiederhergestellt wurden, funktioniert Live Unit Testing nicht. Dieses Problem sollte durch eine explizite Erstellung der Projektmappe oder das Wiederherstellen von NuGet-Paketen in der Projektmappe vor dem Aktivieren von Live Unit Testing behoben werden.

• Wenn Sie MSTest-basierte Tests in den Projekten verwenden, stellen Sie sicher, dass Sie den Verweis auf Microsoft.VisualStudio.QualityTools.UnitTestFramework entfernen und Verweise auf die neuesten MSTest-NuGet-Pakete MSTest.TestAdapter (Mindestversion 1.1.11 ist erforderlich) und MSTest.TestFramework (Mindestversion 1.1.11 ist erforderlich) hinzufügen. Weitere Informationen finden Sie im Abschnitt „Unterstützte Testframeworks“ im Artikel Verwenden von Live Unit Testing in Visual Studio.

• Mindestens ein Projekt in der Projektmappe muss einen NuGet-Verweis oder einen direkten Verweis auf das xUnit-, NUnit- oder MSTest-Testframework aufweisen. Dieses Projekt sollte auch auf ein entsprechendes NuGet-Paket mit Visual Studio-Testadaptern verweisen.

Die Buildfehler werden im Ausgabefenster gemeldet, wenn die Dropdownliste „Live Unit Testing“ ausgewählt ist. Es gibt einige gängige Probleme, die durch eine fehlerhafte Konfiguration im Setup-Assistenten verursacht werden und die zu Buildproblemen in Live Unit Testing führen können.

• Wenn die Eigenschaft für den Arbeitsbereichsstamm zu lang ist, kann der Build durch Ausnahmen aufgrund einer übermäßigen Pfadlänge fehlschlagen.

• Wenn die Eigenschaft für den Repositorystamm nicht auf den Repositorystamm zeigt, wird der Arbeitsbereich mit den falschen Dateien aufgefüllt.

• Bei Git-Repositorys wird das Kopieren der Dateien, die in der GITIGNORE-Datei aufgeführt sind, normalerweise durch die Eigenschaft Dateien ausschließen vermieden. Es ist jedoch möglich, Dateien in das Git-Repository einzuchecken, die ignoriert werden, oder Tools zum automatischen Generieren von Dateien auszuführen, die aber während des Builds nicht generiert werden. In diesen Fällen sollte die Option <Benutzerdefiniert> ausgewählt und ein benutzerdefinierter Regelsatz aufgelistet werden, der nur die Artefaktordner enthält.

Neben den zuvor beschriebenen Problemen führen folgende Projektkonfigurationen möglicherweise zu einem fehlerhaften Build.

• Wenn Projektabhängigkeiten als globale Projektmappenkonfiguration und nicht als ProjectReferences für die einzelnen Projekte angegeben werden, erstellt Live Unit Testing möglicherweise die falschen Menge von Projekten. Um dieses Problem zu beheben, fügen Sie explizite Verweise zwischen Projekten hinzu.

• Bis eine Live Unit Testing-Wiedergabeliste ausgewählt wird, erstellt Live Unit Testing keine Projekte. Um dies zu beheben, nehmen Sie einige Tests in die Live Unit Testing-Wiedergabeliste auf.

• Wenn Sie MSTest-basierte Tests in den Projekten verwenden, stellen Sie sicher, dass Sie den Verweis auf Microsoft.VisualStudio.QualityTools.UnitTestFramework entfernen und Verweise auf die neuesten MSTest-NuGet-Pakete MSTest.TestAdapter (Mindestversion 1.1.11 erforderlich) und MSTest.TestFramework (Mindestversion 1.1.11 erforderlich) hinzufügen. Weitere Informationen finden Sie unter Unterstützte Testframeworks.

• Mindestens ein Projekt in der Projektmappe muss einen NuGet-Verweis oder einen direkten Verweis auf das xUnit-, NUnit- oder MSTest-Testframework aufweisen. Dieses Projekt sollte auch auf ein entsprechendes NuGet-Paket mit Visual Studio-Testadaptern verweisen. Auf den Visual Studio-Testadapter kann auch über eine .runsettings-Datei verwiesen werden. Die .runsettings-Datei muss einen Eintrag wie im folgenden Beispiel enthalten:

<RunSettings>
    <RunConfiguration>
          <TestAdaptersPaths>path-to-your-test-adapter</TestAdaptersPaths>
    </RunConfiguration>
</RunSettings>

• Ein häufiges Problem besteht darin, dass nicht alle Dateien in den Testordner kopiert werden. Möglicherweise müssen Sie den CSPROJ-Dateien einige Live Unit Testing-Testabhängigkeitselemente hinzufügen.

• Timeouts sind ein weiteres Problem. Da Tests bei Live Unit Testing auf unbestimmte Zeit ausgeführt werden, wird eine Ausführung nach zu langer Dauer automatisch abgebrochen. Sie können das Timeout im Assistenten des Projekts erhöhen.

• Wenn mehrere Projekte in der Projektmappe auf das NuGet-Testadapterpaket verweisen, muss jedes auf die unterstützte Version upgegradet werden.

• Stellen Sie sicher, dass die Datei „MSBuild .props“, die aus dem Testadapterpaket importiert wurde, ebenfalls ordnungsgemäß aktualisiert wird. Überprüfen Sie die NuGet-Paket Version bzw. den Pfad des Imports, der sich in der Regel am Anfang der Datei befindet, z.B.:

    <Import Project="..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props" Condition="Exists('..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props')" />
  

Wenn Ihre Projektmappe benutzerdefinierte Schritte für einen Build mit Instrumentierung erfordert (Live Unit Testing), die für den „normalen“, nicht instrumentierten Build nicht erforderlich sind, können Sie dem Projekt oder den TARGETS-Dateien Code hinzufügen, der auf die Eigenschaft BuildingForLiveUnitTesting prüft und vorab oder anschließend benutzerdefinierte Buildschritte ausführt. Sie können basierend auf dieser Eigenschaft auch bestimmte Buildschritte entfernen (z.B. Veröffentlichen oder Generieren von Paketen) oder einem Live Unit Testing-Build Buildschritte hinzuzufügen (z.B. Kopieren der erforderlichen Komponenten). Das Anpassen Ihres Builds basierend auf dieser Eigenschaft verändert Ihren „normalen“ Build in keinster Weise und hat nur Auswirkungen auf Live Unit Testing-Builds.

Möglicherweise gibt es z.B. ein Ziel, das NuGet-Pakete während eines regulären Buildvorgangs erzeugt. Sie möchten wahrscheinlich nicht, dass NuGet-Pakete nach jeder Änderung generiert werden. Also können Sie dieses Ziel im Live Unit Testing-Build deaktivieren, indem Sie z.B. Folgendes ausführen:

<Target Name="GenerateNuGetPackages" BeforeTargets="AfterBuild" Condition="'$(BuildingForLiveUnitTesting)' != 'true'">
    <Exec Command='"$(MSBuildThisFileDirectory)..\tools\GenPac" '/>
</Target>

Es gibt mehrere Unterschiede:

• Beim Ausführen oder Debuggen von Tests im Fenster Test-Explorer werden reguläre Binärdateien ausgeführt. Live Unit Testing führt dagegen instrumentierte Binärdateien aus. Wenn Sie instrumentierte Binärdateien debuggen möchten, wird durch das Hinzufügen eines Debugger.Launch-Methodenaufrufs in der Testmethode der Debugger bei jeder Ausführung der Methode gestartet (auch bei der Ausführung durch Live Unit Testing), und Sie können dann die instrumentierte Binärdatei anfügen und debuggen. Wir hoffen jedoch, dass die Instrumentierung der meisten Benutzerszenarien für Sie transparent ist und Sie instrumentierte Binärdateien nicht debuggen müssen.

• Live Unit Testing erstellt keine neue Anwendungsdomäne zum Ausführen von Tests. Tests, die im Fenster Test-Explorer ausgeführt werden, erstellen dagegen eine neue Anwendungsdomäne.

• Live Unit Testing führt Tests in allen Testassemblys nacheinander aus. Im Test-Explorer können Sie auswählen, mehrere Tests parallel auszuführen.

• Test-Explorer führt Tests standardmäßig in einem Singlethread-Apartment (STA) aus, während Live Unit Testing Tests in einem Multithread-Apartment (MTA) ausführt. Um MSTest-Tests in STA in Live Unit Testing auszuführen, versehen Sie die Testmethode oder die enthaltende Klasse mit dem <STATestMethod>- oder dem <STATestClass>-Attribut, das im NuGet-Paket MSTest.STAExtensions 1.0.3-beta enthalten ist. Ergänzen Sie für NUnit die Testmethode mit dem <RequiresThread(ApartmentState.STA)>-Attribut, und für xUnit mit dem <STAFact>-Attribut.

Die benutzerspezifische Einstellung finden Sie im Abschnitt „Einschließen und Ausschließen von Testprojekten und Testmethoden“ im Artikel Verwenden von Live Unit Testing in Visual Studio. Das Ein- und Ausschließen von Tests ist nützlich, wenn Sie eine bestimmte Reihe von Tests für eine bestimmte Bearbeitungssitzung ausführen möchten oder Ihre eigenen persönlichen Einstellungen beibehalten möchten.

Bei spezifischen Einstellungen von Projektmappen können Sie das System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute-Attribut programmgesteuert anwenden, um Methoden, Eigenschaften, Klassen oder Strukturen von der Instrumentierung durch Live Unit Testing auszuschließen. Darüber hinaus können Sie auch die <ExcludeFromCodeCoverage>-Eigenschaft in der Projektdatei auf true festlegen, um zu verhindern, dass das gesamte Projekt instrumentiert wird. Live Unit Testing führt die Tests dennoch aus, die nicht instrumentiert wurden, aber deren Abdeckung wird nicht visuell dargestellt.

Sie können auch überprüfen, ob Microsoft.CodeAnalysis.LiveUnitTesting.Runtime in der aktuellen Anwendungsdomäne geladen wird und auf dieser Grundlage Tests deaktivieren. Beispielsweise können Sie mit xUnit Folgendes ausführen:

[ExcludeFromCodeCoverage]
public class SkipLiveFactAttribute : FactAttribute
{
   private static bool s_lutRuntimeLoaded = AppDomain.CurrentDomain.GetAssemblies().Any(a => a.GetName().Name ==
                                            "Microsoft.CodeAnalysis.LiveUnitTesting.Runtime");
   public override string Skip => s_lutRuntimeLoaded ? "Test excluded from Live Unit Testing" : "";
}

public class Class1
{
   [SkipLiveFact]
   public void F()
   {
      Assert.True(true);
   }
}

Ihre Projektmappe kann sogar erstellt werden, wenn Sie keine Änderungen vornehmen, wenn der Buildvorgang Quellcode generiert, der Teil der Projektmappe selbst ist, und in den Zieldateien des Builds keine entsprechenden Eingaben und Ausgaben angegeben sind. Zielen sollte eine Liste von Eingaben und Ausgaben bereitgestellt werden, damit MSBuild die entsprechenden aktuellen Überprüfungen vornehmen kann und bestimmen kann, ob ein neuer Build erforderlich ist.

Live Unit Testing startet einen Buildvorgang, wenn erkannt wird, dass Quelldateien geändert wurden. Da der Buildvorgang Ihrer Projektmappe Quelldateien generiert, gerät Live Unit Testing in eine unendliche Buildschleife. Wenn die Eingaben und Ausgaben des Ziels jedoch überprüft werden, wenn Live Unit Testing den zweiten Buildvorgang startet (nach der Ermittlung neu generierter Quelldateien aus dem vorherigen Build), wird die Buildschleife unterbrochen, da die Überprüfungen der Eingaben und Ausgaben darauf hinweisen, dass alles auf dem neuesten Stand ist.

Es werden möglicherweise keine Symbole im Editor angezeigt, wenn die Assemblys, die von Live Unit Testing verarbeitet werden, nicht instrumentiert werden. Beispielsweise ist Live Unit Testing nicht kompatibel mit Projekten, die <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable> festlegen. In diesem Fall muss der Buildvorgang aktualisiert werden, um diese Einstellung zu entfernen oder in true zu ändern, damit Live Unit Testing funktioniert. 

Sie haben mehrere Möglichkeiten, um ausführlichere Protokolle zu sammeln:

• Wechseln Sie zu Extras>Optionen>Live Unit Testing, und ändern Sie die Protokollierungsoption in Ausführlich. Durch die ausführliche Protokollierung werden detailliertere Protokolle im Ausgabefenster angezeigt.

• Legen Sie die LiveUnitTesting_BuildLog-Benutzerumgebungsvariable auf den Namen der Datei fest, die Sie verwenden möchten, um das MSBuild-Protokoll zu erfassen. Detaillierte MSBuild-Protokollmeldungen von Live Unit Testing-Builds können dann aus dieser Datei abgerufen werden.

• Legen Sie die UmgebungsvariableLiveUnitTesting_TestPlatformLog auf 1 fest, um das Protokoll der Testplattform zu erfassen. Detaillierte Testplattform-Protokollmeldungen zu Live Unit Testing-Ausführungen können dann aus [Solution Root]\.vs\[Solution Name]\log\[VisualStudio Process ID] abgerufen werden.

• Erstellen Sie eine Umgebungsvariable auf Benutzerebene mit dem Namen VS_UTE_DIAGNOSTICS, legen Sie sie auf 1 (oder einen beliebigen Wert) fest, und starten Sie Visual Studio neu. Jetzt sollten Sie eine umfangreiche Protokollierung auf der Registerkarte Ausgabe – Tests in Visual Studio sehen.

Nein, Sie sollten die Dateien in den Build- und Testverzeichnissen des Arbeitsbereichsordners nicht öffnen oder bearbeiten. Live Unit Testing sollte alle Dateien im Ordner src verwalten, um die Synchronisierung zwischen dem Repositorystamm und dem Arbeitsbereichsstamm zu gewährleisten.

Ja, aber Sie müssen sicherstellen, dass es aktiviert ist. Wenn Sie ein Entwicklerlaufwerk verwenden, stellen Sie sicher, dass der Filter ProjFS (Projected File System) aktiviert ist. Der folgende Befehl aktiviert beispielsweise ProjFS und Windows Defender:

fsutil devdrv setfiltersallowed PrjFlt, WdFilter

Siehe auch

• Live-Komponententests