Häufig gestellte Fragen zum Testen von Live-Komponenten

Live Unit Testing funktioniert mit den drei beliebten Komponententestframeworks, die in der folgenden Tabelle aufgeführt sind. Die mindestens unterstützte Version ihrer Adapter und Frameworks ist auch in der Tabelle aufgeführt. Die Komponententestframeworks sind alle über NuGet.org verfügbar.

Wenn Sie ältere MSTest-basierte Testprojekte haben, die auf Microsoft.VisualStudio.QualityTools.UnitTestFramework verweisen und nicht zu den neueren MSTest NuGet-Paketen wechseln möchten, führen Sie ein Upgrade auf Visual Studio 2019 oder Visual Studio 2017 durch.

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

Das Ausgabefenster (wenn die Dropdownliste "Live Unit Testing" 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 NuGet-Pakete, auf die von den Projekten in der Lösung verwiesen wird, nicht wiederhergestellt wurden, funktioniert das Testen von Live-Komponenten nicht. Das Ausführen eines expliziten Builds der Lösung oder das Wiederherstellen von NuGet-Paketen in der Lösung vor dem Aktivieren von Live Unit Testing sollte dieses Problem beheben.

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

• Mindestens ein Projekt in Ihrer Lösung sollte entweder einen NuGet-Verweis oder direkten Verweis auf das xUnit-, NUnit- oder MSTest-Testframework aufweisen. Dieses Projekt sollte auch auf ein entsprechendes Visual Studio-Testadapter-NuGet-Paket verweisen.

Die Buildfehler werden dem Ausgabefenster gemeldet, wenn die Dropdownliste "Live Unit Testing" ausgewählt ist. Es gibt einige häufige Probleme, die durch falsche Konfiguration im Setup-Assistenten verursacht werden, die Buildprobleme bei Live Unit Testing verursachen können.

• Wenn die Workspace Root-Eigenschaft zu lang ist, ist es möglich, dass der Build aufgrund von Ausnahmen fehlschlägt, die angeben, dass der Pfad zu lang ist.

• Wenn die Repositorystammeigenschaft nicht auf den Repositorystamm verweist, wird der Arbeitsbereich mit dem falschen Satz von Dateien aufgefüllt.

• Bei Git-Repositorys vermeidet die "Dateien ausschließen" Eigenschaft in der Regel das Kopieren der in der gitignore Datei angegebenen Dateien. Es ist jedoch möglich, Dateien in das git-Repository einzuchecken, das ignoriert wird, oder es ist möglich, Tools auszuführen, die dateien automatisch generieren, aber diese werden während des Builds nicht generiert. In diesen Fällen sollte die Option "<Benutzerdefinierte>" ausgewählt werden, und eine benutzerdefinierte Regelsatz, die nur die Artefaktordner auflisten, sollte aufgelistet werden.

Neben den zuvor beschriebenen Problemen sind die folgenden Projektkonfigurationen, die möglicherweise nicht ordnungsgemäß erstellt wurden.

• Wenn Projektabhängigkeiten als globale Lösungskonfiguration und nicht als ProjectReferences für jedes Projekt angegeben werden, erstellt Live Unit Testing möglicherweise den falschen Satz von Projekten. Fügen Sie zum Beheben dieses Problems explizite Verweise zwischen Projekten hinzu.

• Bis eine Wiedergabeliste für Live-Komponententests ausgewählt wird, erstellt Live Unit Testing keine Projekte. Um dies zu beheben, schließen Sie einige Tests in die Wiedergabeliste "Live Unit Testing" ein.

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

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

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

Live Unit Testing kann die Quellgeneratorprojekte nicht mit Instrumentierung erstellen. Da der C#-Compiler Assemblyladevorgänge für Quellgeneratoren einrichtet, schlägt der Versuch, Quellgeneratorprojekte mit Instrumentierung zu erstellen, keine Live Unit Testing-Assemblys geladen.

Sie können <ExcludeFromCodeCoverage>true</ExcludeFromCodeCoverage> Eigenschaft in den Csproj-Dateien des Quellgenerators festlegen, um diese Projekte in Live Unit Testing zu erstellen.

Live Unit Testing führt den Build aus Leistungsgründen innerhalb eines eigenen Prozesses aus. Wenn dieser separate Buildprozess einen Fehler verursacht, können Sie <UseInProcMSBuildNode>false</UseInProcMSBuildNode> auf die .lutconfig-Datei festlegen, um sicherzustellen, dass der gesamte Build im MSBuild-Prozess erfolgt.

• Ein häufiges Problem besteht darin, dass nicht alle Dateien in den Testordner kopiert werden. Möglicherweise müssen Sie der csproj--Dateien einige Testtesttests Elemente hinzufügen.

• Ein weiteres Problem ist Timeouts. Da Live Unit Testing auf unbestimmte Zeit Tests ausführt, wird eine Ausführung automatisch abgebrochen, wenn die Tests zu lang ausgeführt werden. Sie können das Timeout im Assistenten des Projektserhöhen.

• Wenn mehrere Projekte in der Lösung auf das NuGet-Testadapterpaket verweisen, muss jedes von ihnen auf die unterstützte Version aktualisiert werden.

• Stellen Sie sicher, dass auch die aus dem Testadapterpaket importierte MSBuild-.props Datei korrekt aktualisiert wird. Überprüfen Sie die NuGet-Paketversion/den Pfad des Imports, die in der Regel am oberen Rand der Projektdatei zu finden ist, wie die folgenden:

    <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 Lösung benutzerdefinierte Schritte zum Erstellen für die Instrumentierung (Live Unit Testing) erfordert, die für den "regulären" nicht instrumentierten Build nicht erforderlich sind, können Sie Ihrem Projekt Code hinzufügen oder .targets Dateien, die auf die BuildingForLiveUnitTesting-Eigenschaft überprüfen und benutzerdefinierte Vor-/Nach-Buildschritte ausführen. Sie können auch bestimmte Buildschritte entfernen (z. B. Veröffentlichen oder Generieren von Paketen) oder Buildschritte (z. B. Kopieren von Voraussetzungen) zu einem Live Unit Testing-Build basierend auf dieser Projekteigenschaft hinzufügen. Das Anpassen Ihres Builds auf Der Grundlage dieser Eigenschaft ändert ihren regulären Build nicht und wirkt sich nur auf Live Unit Testing-Builds aus.

Es kann z. B. ein Ziel geben, das NuGet-Pakete während eines regulären Builds erzeugt. Sie möchten wahrscheinlich nicht, dass NuGet-Pakete nach jeder Von Ihnen vorgenommenen Bearbeitung generiert werden. Sie können dieses Ziel also im Live Unit Testing-Build deaktivieren, indem Sie etwa wie folgt vorgehen:

<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 aus dem Test-Explorer Fensters werden normale Binärdateien ausgeführt, während live Unit Testing instrumentierte Binärdateien ausführt. Wenn Sie instrumentierte Binärdateien debuggen möchten, führt das Hinzufügen eines Debugger.Launch Methodenaufrufs in Der Testmethode dazu, dass der Debugger immer gestartet wird, wenn diese Methode ausgeführt wird (einschließlich 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 für die meisten Benutzerszenarien transparent ist und dass Sie keine instrumentierten Binärdateien debuggen müssen.

• Live Unit Testing erstellt keine neue Anwendungsdomäne zum Ausführen von Tests, aber Tests werden aus dem Fenster Test-Explorer Fenster ausgeführt, um eine neue Anwendungsdomäne zu erstellen.

• Live Unit Testing führt Tests in jeder Testassembly sequenziell aus. Im Test-Explorerkönnen Sie mehrere Tests parallel ausführen.

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

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

Für lösungsspezifische Einstellungen können Sie das System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute-Attribut programmgesteuert anwenden, um Methoden, Eigenschaften, Klassen oder Strukturen von der Instrumentierbarkeit von Live Unit Testing auszuschließen. Darüber hinaus können Sie die <ExcludeFromCodeCoverage>-Eigenschaft auch so festlegen, dass sie in Ihrer Projektdatei true, um das gesamte Projekt davon auszuschließen, dass es instrumentiert wird. Live Unit Testing führt weiterhin die Tests aus, die noch nicht instrumentiert wurden, aber ihre Abdeckung wird nicht visualisiert.

Sie können auch überprüfen, ob Microsoft.CodeAnalysis.LiveUnitTesting.Runtime in der aktuellen Anwendungsdomäne geladen wird, und Tests basierend auf dem Grund deaktivieren. Sie können z. B. etwa wie folgt mit xUnit vorgehen:

[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 Lösung kann auch dann erstellt werden, wenn Sie keine Bearbeitungen vornehmen, wenn der Buildprozess Quellcode generiert, der Teil der Lösung selbst ist, und ihre Buildzieldateien nicht über entsprechende Eingaben und Ausgaben verfügen. Zielvorgaben sollten eine Liste von Eingaben und Ausgaben erhalten, damit MSBuild die entsprechenden up-to-Datumsprüfungen durchführen und bestimmen kann, ob ein neuer Build erforderlich ist.

Live Unit Testing startet einen Build, wenn erkannt wird, dass sich Quelldateien geändert haben. Da der Build Ihrer Lösung Quelldateien generiert, erhält Live Unit Testing eine unendliche Buildschleife. Wenn die Eingaben und Ausgaben des Ziels jedoch überprüft werden, wenn Live Unit Testing den zweiten Build startet (nachdem die neu generierten Quelldateien aus dem vorherigen Build erkannt wurden), wird die Buildschleife unterbrochen, da die Eingabe- und Ausgabeprüfungen darauf hindeuten, dass alles up-to-datum ist.

Möglicherweise werden im Editor keine Symbole angezeigt, wenn die Assemblys, auf denen Live Unit Testing ausgeführt wird, aus irgendeinem Grund nicht instrumentiert sind. Beispielsweise ist Live Unit Testing nicht mit Projekten kompatibel, die <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>festlegen. In diesem Fall muss Ihr Buildprozess aktualisiert werden, um diese Einstellung zu entfernen oder in true zu ändern, damit Live Unit Testing funktioniert. 

Sie können mehrere Aktionen ausführen, um detailliertere Protokolle zu sammeln:

• Wechseln Sie zu Tools>Optionen>Live Unit Testing, und ändern Sie die Protokollierungsoption in ausführliche. Ausführliche Protokollierung bewirkt, dass detailliertere Protokolle im Fenster Ausgabe angezeigt werden.

• Legen Sie die LiveUnitTesting_BuildLog Benutzerumgebungsvariable auf den Namen der Datei fest, die Sie zum Erfassen des MSBuild-Protokolls verwenden möchten. Detaillierte MSBuild-Protokollmeldungen aus Live Unit Testing-Builds können dann aus dieser Datei abgerufen werden.

• Legen Sie die LiveUnitTesting_TestPlatformLog Benutzerumgebungsvariable auf 1 fest, um das Testplattformprotokoll zu erfassen. Detaillierte Testplattformprotokollmeldungen aus Live Unit Testing-Ausführung 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, und legen Sie sie auf 1 (oder einen beliebigen Wert) fest, und starten Sie Visual Studio neu. Nun sollten viele Protokollierungen in der Ausgabe angezeigt werden – Tests Registerkarte in Visual Studio.

Nein, Sie sollten die Dateien nicht unter den Build- und Testverzeichnissen des Arbeitsbereichsordners öffnen oder bearbeiten. Live Unit Testing sollte alle Dateien im ordner src verwalten, damit sie zwischen dem Repositorystamm- und Arbeitsbereichstamm-synchronisiert werden.

Ja, aber Sie müssen sicherstellen, dass sie aktiviert ist. Wenn Sie ein Dev Drive verwenden, stellen Sie sicher, dass das projizierten Dateisystems (ProjFS) Filter aktiviert ist. Der folgende Befehl aktiviert z. B. ProjFS und Windows Defender:

fsutil devdrv setfiltersallowed PrjFlt,WdFilter

Siehe auch

• Live-Komponententests