Konfigurieren und Verwenden von Live Unit Testing

  • Artikel

Während Sie eine Anwendung entwickeln, führt Live Unit Testing automatisch alle erforderlichen Komponententests im Hintergrund aus und zeigt Ergebnisse und Code Coverage in Echtzeit an. Wenn Sie Ihren Code ändern, bietet Live Unit Testing Feedback dazu, wie sich Ihre Änderungen auf vorhandene Tests auswirken und ob der von Ihnen hinzugefügte Code durch einen oder mehrere vorhandene Tests abgedeckt ist. Dieses Feedback erinnert Sie daran, Komponententests zu schreiben, während Sie Fehlerkorrekturen vornehmen oder neue Features hinzufügen.

Wenn Sie Live Unit Testing für Ihre Tests verwenden, werden Daten zum Status Ihrer Tests beibehalten. Da bei Live Unit Testing persistente Daten verwendet werden können, bietet es eine überragende Leistung bei der dynamischen Ausführung Ihrer Tests in Bezug auf Codeänderungen.

Live Unit Testing ist nur in der Enterprise-Edition von Visual Studio für Projekte verfügbar, die auf .NET Core oder .NET Framework ausgerichtet sind.

Unterstützte Testframeworks

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 aufgeführt. Die Frameworks für Komponententests sind auf „NuGet.org“ verfügbar.

Testframework Mindestversion des Visual Studio-Adapters Mindestversion des Frameworks
xUnit.net xunit.runner.visualstudio, Version 2.2.0-beta3-build1187 xUnit 1.9.2
NUnit NUnit3TestAdapter, Version 3.5.1 NUnit, Version 3.5.0
MSTest MSTest.TestAdapter 1.1.4-preview MSTest.TestFramework 1.0.5-preview

Wenn Sie über ältere auf MSTest-basierende Testprojekte verfügen, die auf Microsoft.VisualStudio.QualityTools.UnitTestFramework verweisen, und Sie nicht auf die neueren MSTest-NuGet-Pakete umsteigen möchten, führen Sie ein Upgrade Sie auf Visual Studio 2019 oder Visual Studio 2017 durch.

In einigen Fällen müssen Sie die NuGet-Pakete, auf die ein Projekt in der Projektmappe verweist, explizit wiederherstellen, damit Live Unit Testing funktioniert. Sie verfügen über zwei Möglichkeiten:

  • Stellen Sie die Projektmappe wieder her, indem Sie einen expliziten Build der Projektmappe ausführen. Wählen Sie Erstellen>Projektmappe neu erstellen im Visual Studio-Menü der obersten Ebene aus.
  • Stellen Sie Pakete in der Projektmappe wieder her. Klicken Sie mit der rechten Maustaste auf die Projektmappe, und wählen Sie NuGet-Pakete wiederherstellen aus.

Konfigurieren

Beim ersten Starten von Live Unit Testing für eine Projektmappe können Sie in einem Setup-Assistenten konfigurieren, wie Tests in Live Unit Testing erstellt und ausgeführt werden sollen.

Wenn Live Unit Testing beendet wird, können Sie den Setup-Assistenten auch öffnen, indem Sie zu Test>Live Unit Testing>Live Unit Testing für Projektmappe konfigurieren wechseln.

Wenn Live Unit Testing ausgeführt wird, wird ein Arbeitsbereich erstellt, der eine Kopie des ursprünglichen Repositorys ist. Live Unit Testing wendet dann alle nicht gespeicherten Änderungen, die Sie in Visual Studio vorgenommen haben, auf den Arbeitsbereich an, führt einen Build aus, führt einen Testlauf aus und meldet die neueste Code Coverage.

Als Erstes sollten Sie mithilfe des Assistenten konfigurieren, von wo nach wo die Dateien kopiert werden sollen.

Screenshot des Konfigurations-Assistenten für Live Unit Testing auf Seite 1.

Repositorystamm

Der Repositorystamm gibt den Ordner an, der kopiert wird, um den Live Unit Testing-Arbeitsbereich zu erstellen. Hierbei sollte es sich um den Stammordner des Repositorys handeln, d. h. er sollte alle Quellen, Binärdateien und Tools enthalten. In Fällen, in denen die Projektmappendatei im Repositorystamm nicht vorhanden ist, muss der Repositorystamm möglicherweise geändert werden.

Arbeitsbereichsstamm

Der Arbeitsbereichsstamm gibt den Ordner an, in dem Live Unit Testing einen Klon des Repositorys speichert. Achten Sie auf Ausnahmen, die darauf hinweisen, dass der Pfad zu lang ist. Standardmäßig wird der Stamm in Ihrem Startordner erstellt. Wenn Sie Ihr Repository z. B. normalerweise in Laufwerk C erstellen müssen, könnte der Arbeitsbereichsstamm etwa so angepasst werden: C:\lut\Repo.

Angeben der ausgeschlossenen Dateien

Nicht alle Dateien sollten in den Live Unit Testing-Arbeitsbereich kopiert werden. Jegliche Artefakte, die während des Builds generiert werden, sollten aus dem Kopiervorgang ausgeschlossen werden, damit es keine Konflikte zwischen den regulären Builds und den Live Unit Testing-Builds gibt. Außerdem sollte der reguläre nuget restore-Befehl keinen Konflikt mit dem Live Unit Testing-Befehl nuget restore verursachen.

Standardmäßig schließt Live Unit Testing eines der beiden Dateimuster aus:

  • Bei Git-Repositorys werden Dateien, die in der gitignore-Datei angegeben sind, nicht in den Live Unit Testing-Arbeitsbereich kopiert.
  • Bei Nicht-Git-Repositorys werden keine grundlegenden Ordnerlisten wie bin/ und obj/ in den Live Unit Testing-Arbeitsbereich kopiert.

Bei komplexeren Repositorys müssen Sie möglicherweise selbst eine ignore-Datei angeben. Wählen Sie im Assistenten die Option <Benutzerdefiniert> aus. Nach der Auswahl von Weiter wird der Inhalt einer benutzerdefinierten ignore-Datei angezeigt, die Live Unit Testing erstellt, sobald der Assistent abgeschlossen ist. Dabei handelt es sich u m die Datei lutignore.

Hinweis

Für einige Git-Repositorys ist eine benutzerdefinierte lutignore-Datei erforderlich, da es möglich ist, Dateien in das Git-Repository einzuchecken, die auch von der gitignore-Datei ignoriert werden. Ohne eine benutzerdefinierte lutignore-Datei kopiert Live Unit Testing diese Dateien nicht, was zu Buildfehlern führen kann.

Struktur der lutignore-Datei

Die lutignore-Datei verwendet das gleiche Format wie eine gitignore-Datei. Sie sollte Regeln entsprechend den Ordnern oder Dateien enthalten, die während des Builds generiert werden, damit sie nicht in den Arbeitsbereich kopiert werden. Für die meisten der Standardprojektvorlagen reicht die folgende ignore-Datei aus:

[BB]IN
[OO]BJ
# WILL NOT COPY ANY BIN AND OBJ FOLDERS TO THE LIVE UNIT TESTING WORKSPACE

Wenn Ihr Repository über einen einzigen Buildordner verfügt, sollte die ignore-Datei stattdessen diesen Ordner auflisten:

[AA]RTIFACTS/
# WILL NOT COPY THE ARTIFACTS FOLDER TO THE LIVE UNIT TESTING WORKSPACE

Wenn Ihr Repository weitere Tools im Buildordner enthält, sollten diese Tools in der Gruppe der Abgleichsmuster ausgeschlossen werden:

[AA]RTIFACTS/
![AA]RTIFACTS/TOOLS/
# WILL NOT COPY THE ARTIFACTS FOLDER TO THE LIVE UNIT TESTING WORKSPACE
# HOWEVER IT WILL COPY THE TOOLS SUBFOLDER THAT MIGHT CONTAIN TOOLS AND UTILITIES

Buildoptionen

Im zweiten Teil der Assistentenkonfigurationsseite konfigurieren Sie Buildoptionen:

  • PDBs erstellen: Um den Buildvorgang zu beschleunigen, generiert Live Unit Testing während der Builderstellung keine PDBs. Mit diesen Symboldateien können Sie zu den Stapelablaufverfolgungen wechseln, wenn Testfehler auftreten.
  • Mithilfe mehrerer CPU-Kerne erstellen: Standardmäßig erstellt Live Unit Testing Builds unter Verwendung mehrerer CPU-Kerne, was den Buildvorgang beschleunigt. Wenn Ihr Computer langsam wird oder Ihre Projektmappe nicht mit mehreren Kernen erstellt werden kann, wählen Sie diese Option nicht aus.

Optionen für die Testausführung

Im letzten Teil der Assistentenkonfigurationsseite richten Sie die Optionen für die Testausführung ein:

  • Timeout für Testfälle: Einige der Tests können lange dauern. Wenn Sie diese Option angeben, werden Ausführungen automatisch abgebrochen, wenn einer der Tests eine bestimmte Zeitdauer überschreitet. Die Tests können automatisch abgebrochen werden.
  • Mehrere Prozessoren verwenden: Standardmäßig versucht Live Unit Testing, mehrere Prozessoren zu verwenden, um die Ausführung zu beschleunigen. Wenn Ihr Computer langsam wird oder Ihre Projektmappe Tests nicht parallel ausführen kann, wählen Sie diese Option nicht aus. Diese Szenarien können beispielsweise auftreten, wenn mehrere Tests versuchen, in denselben Dateipfaden zu schreiben oder zu lesen.

Weitere Konfigurationen

Konfigurieren Sie Live Unit Testing, indem Sie Tools>Optionen auf der Menüleiste der obersten Ebene von Visual Studio auswählen. Wählen Sie im linken Bereich des Dialogfelds Optionen den Eintrag Live Unit Testing aus.

Nach der Aktivierung von Live Unit Testing (siehe Starten, Anhalten und Beenden von Live Unit Testing) können Sie das Dialogfeld Optionen öffnen, indem Sie Test>Live Unit Testing>Optionen auswählen.

Die folgende Abbildung zeigt die im Dialogfeld verfügbaren Konfigurationsoptionen für Live Unit Testing.

Screenshot, der die Konfigurationsoptionen für Live Unit Testing zeigt.

Die konfigurierbaren Optionen umfassen Folgendes:

  • Ob Live Unit Testing angehalten wird, wenn eine Projektmappe erstellt und ein Debugging durchgeführt wird.

  • Ob Live Unit Testing angehalten wird, wenn die Akkuleistung des Systems unter einen bestimmten Schwellenwert sinkt.

  • Die Fähigkeit, alle persistenten Daten zu löschen. Diese Funktion ist hilfreich, wenn sich Live Unit Testing auf unvorhersehbare oder unerwartete Weise verhält, was darauf hinweist, dass die persistenten Daten beschädigt sind.

  • Die maximale Arbeitsspeichermenge, die Live Unit Testing-Prozesse belegen können.

  • Den Umfang an Informationen, der in das Live Unit Testing-Fenster Ausgabe geschrieben wird.

    Mögliche Optionen sind: Keine Protokollierung (Keine), nur Fehlermeldungen (Fehler), Fehler- und Informationsmeldungen (Info, die Standardeinstellung) oder alle Details (Ausführlich).

    Sie können auch eine ausführlichen Ausgabe im Live Unit Testing-Fenster Ausgabe anzeigen, indem Sie einer Umgebungsvariablen auf Benutzerebene mit dem Namen VS_UTE_DIAGNOSTICS den Wert 1 zuweisen. Starten Sie Visual Studio dann neu.

    Um detaillierte MSBuild-Protokollmeldungen von Live Unit Testing in einer Datei aufzuzeichnen, legen Sie die LiveUnitTesting_BuildLog-Umgebungsvariable auf Benutzerebene auf den Namen der Datei fest, die das Protokoll enthalten soll.

Anpassen Ihres Builds für Live Unit Testing

Bei komplexeren Lösungen kann es erforderlich sein, den Build weiter anzupassen. Beispiel: Möglicherweise müssen während der Testausführung keine Übersetzungsdateien erstellt werden. Um Ihre Builds zu beschleunigen, können Sie den Build der Übersetzungsdatei mit Live Unit Testing deaktivieren. Bearbeiten Sie zu diesem Zweck die Projektdateien.

Hinzufügen von Außerkraftsetzungen für Live Unit Testing

Wenn Ihre Projektmappe benutzerdefinierte Schritte für einen Buildvorgang zur Instrumentierung erfordert (Live Unit Testing), die für den „normalen“, nicht instrumentierten Build nicht erforderlich sind, dann können Sie Code zum Projekt oder zu .targets-Dateien hinzufügen, der auf die Eigenschaft BuildingForLiveUnitTesting prüft und vor oder nach dem Build benutzerdefinierte Schritte ausführt.

Sie können z. B. Code wie im folgenden Beispiel schreiben, um ein weiteres Ziel hinzuzufügen, das nur für Live Unit Testing ausgeführt wird:

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

Sie können die Eigenschaft BuildingForLiveUnitTesting verwenden, um einige Aufgaben zu deaktivieren, die bei Testbuilds nicht ausgeführt werden sollten. Beispielsweise legt Live Unit Testing <RunAnalyzers>false</RunAnalyzers> fest, um Analysemodule für Tests zu deaktivieren.

Testabhängigkeiten bei Live Unit Testing

Es ist möglich, dass nicht alle Dateien kopiert wurden, die für die Ausführung der Tests erforderlich sind. Live Unit Testing erstellt einen separaten Ordner, in dem Tests ausgeführt werden. Auf diese Weise können Builds ausgeführt werden, während die Tests laufen, es werden aber nicht alle Dateien aus dem Buildordner in den Testordner kopiert.

In der Regel fügen Sie Testabhängigkeiten aus einem von zwei Gründen hinzu:

  • Ihre Tests benötigen Dateien in der Quellstruktur. Beispielsweise untersuchen die Tests den Inhalt der resx-Dateien oder lesen möglicherweise einige Konfigurationsdateien.
  • Ihre Tests benötigen einige Bibliotheken, auf die sie verweisen. Beispielsweise führt ein Test eine ausführbare Datei aus, die als Abhängigkeit erstellt wurde.

Hinweis

Testabhängigkeiten müssen in dem Verzeichnis vorhanden sein, das im Setup-Assistenten als Repositorystamm angegeben ist.

In beiden Fällen kopiert Live Unit Testing diese Dateien standardmäßig nicht, um die Anzahl der Dateien zu minimieren, die kopiert werden müssen, damit ein Test ausgeführt werden kann. Sie müssen diese Dateien explizit mithilfe der Eigenschaft LiveUnitTestingTestDependency angeben, wenn sie für eine Testausführung erforderlich sind. Nehmen wir beispielsweise an, dass wir über das folgende Layout verfügen:

SRC/
  CONSOLE_UTILITY/
  TEST_PROJECT/
ARTIFACTS/
  CONSOLE_UTILITY/NET472/DEBUG/
  TEST_PROJECT/NET472/DEBUG/

Wenn Sie diese Projekte mit Live Unit Testing erstellen, wird standardmäßig nur Artifacts/Test_Project in den Testordner kopiert. Um dem Testordner Quellen oder die console_utility hinzuzufügen, fügen Sie das folgende Beispiel zu test_project.csproj hinzu:

<LiveUnitTestingTestDependency Include=”$(RepoRoot)/Src/ConsoleUtility” />
<LiveUnitTestingTestDependency Include=”$(RepoRoot)/Artifacts/ConsoleUtility/net472/$(Configuration)/</LiveUnitTestingTestDependency” />

Starten, Anhalten und Beenden

Um Live Unit Testing zu aktivieren, wählen Sie im Visual Studio-Menü der obersten Ebene Test>Live Unit Testing>Starten aus. Wenn Live Unit Testing aktiviert ist, ändern sich die verfügbaren Optionen im Live Unit Testing-Menü von dem einzelnen Element Starten zu Anhalten und Beenden:

  • Anhalten: Unterbricht Live Unit Testing vorübergehend.

    Wenn Live Unit Testing angehalten wird, wird die Visualisierung für Code Coverage im Editor nicht angezeigt, aber alle gesammelten Daten bleiben erhalten. Um Live Unit Testing fortzusetzen, wählen Sie im Menü Live Unit Testing die Option Weiter aus. Live Unit Testing führt die notwendigen Schritte aus, um alle Änderungen nachzuholen, die vorgenommen wurden, während Live Unit Testing angehalten war, und aktualisiert die Glyphen entsprechend.

  • Beenden: Beendet Live Unit Testing vollständig. Live Unit Testing verwirft alle Daten, die gesammelt wurden.

Wenn Sie Live Unit Testing in einer Projektmappe starten, die kein Komponententestprojekt enthält, werden zwar die Optionen Anhalten und Beenden im Menü Live Unit Testing angezeigt, aber Live Unit Testing wird nicht gestartet. Das Ausgabe-Fenster zeigt eine Nachricht, die mit „No supported test adapters are referenced by this solution...“ (Diese Projektmappe bezieht sich auf keine unterstützten Testadapter...) beginnt.

Sie können Live Unit Testing jederzeit vorübergehend anhalten oder vollständig beenden. Sie können diese Maßnahmen ergreifen, wenn Sie sich beispielsweise mitten in einem Refactoringprozess befinden und wissen, dass Tests sowieso eine Weile lang nicht ordnungsgemäß ausgeführt würden.

Einschließen und Ausschließen von Testprojekten und Testmethoden

Wenn Sie Live Unit Testing starten, wird das Toolfenster „Live Unit Testing“ angezeigt, und Sie werden aufgefordert, die Gruppe der Tests auszuwählen, die von Live Unit Testing getestet werden sollen.

Screenshot des Toolfensters, das angezeigt wird, wenn Live Unit Testing zum ersten Mal gestartet wird.

Wählen Sie bei kleineren Projektmappen, bei denen die Komponententests sehr wenig Zeit in Anspruch nehmen, Alle Tests einschließen aus – mit dieser Option führt Live Unit Testing alle Tests.

Bei größeren Projektmappen mit vielen Testprojekten können Sie mithilfe der Playlist steuern, welche Projekte und welche einzelnen Methoden in einem Projekt von Live Unit Testing berücksichtigt werden. Wenn Sie z.B. eine Projektmappe mit Hunderten von Testprojekten haben, können Sie eine bestimmte Reihe von Testprojekten für Live Unit Testing auswählen.

Sie wählen aus, welche Tests ausgeführt werden sollen, indem Sie eine Live Unit Testing-Playlist bearbeiten, ein Feature, das genauso funktioniert wie Playlists im Test-Explorer.

Es gibt verschiedene Möglichkeiten, die Playlist für Live Unit Testing zu bearbeiten:

  • Toolfenster von Live Unit Testing
  • Code-Editor-Fenster
  • Projektmappen-Explorer
  • Programmgesteuert im Testcode

Live Unit Testing speichert den include-/exclude-Status als Benutzereinstellung, wenn eine Projektmappe geschlossen und erneut geöffnet wird.

Toolfenster von Live Unit Testing

Sie können den Playlist-Editor für die Registerkarte „Live Unit Testing“ verwenden, um Projekte, Namespaces oder Klassen in die Ausführung einzuschließen oder aus ihr auszuschließen. Wählen Sie im Toolfenster Playlist bearbeiten aus.

Sie können Strukturansichtselemente auswählen oder löschen, um Tests einzuschließen oder auszuschließen. Wenn Sie z. B. einen einzelnen Test aktivieren, führt Live Unit Testing diesen bei Änderungen aus. Wenn Sie eine Klasse auswählen, werden alle Tests in dieser Klasse ausgeführt. Jegliche neuen Tests, die dieser Klasse hinzugefügt wurden, werden ebenfalls ausgeführt.

Screenshot, der den Playlist-Editor für Live Unit Testing zeigt.

Code-Editor-Fenster

Im Code-Editor-Fenster können Sie einzelne Testmethoden ein- oder ausschließen. Klicken Sie mit der rechten Maustaste auf die Signatur oder den Haupttext der Testmethode im Code-Editor-Fenster, und wählen Sie eine der folgenden Optionen aus:

  • Live Unit Testing>Einschluss der <ausgewählten Methode>
  • Live Unit Testing>Ausschluss der <ausgewählten Methode>
  • Live Unit Testing>Ausschluss aller Methoden außer der <ausgewählten Methode>

Projektmappen-Explorer

Um die einzelnen Projekte in Komponententests auszuwählen, führen Sie die folgenden Schritte aus, nachdem Live Unit Testing gestartet wurde:

  1. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf die Projektmappe, und wählen Sie Live Unit Testing>Ausschließen aus, um die gesamte Projektmappe auszuschließen.
  2. Klicken Sie mit der rechten Maustaste auf jedes Testprojekt, das Sie in die Tests aufnehmen möchten, und wählen Sie Live Unit Testing>Einschließen aus.

Programmgesteuert im Testcode

Sie können auch das ExcludeFromCodeCoverageAttribute-Attribut anwenden, damit Methoden, Klassen oder Strukturen ihre Abdeckung nicht programmgesteuert in Live Unit Testing ausgeschlossen werden.

Schließen Sie mithilfe der folgenden Attribute einzelne Methoden von Live Unit Testing aus:

  • xUnit: [Trait("Category", "SkipWhenLiveUnitTesting")]
  • NUnit: [Category("SkipWhenLiveUnitTesting")]
  • MSTest: [TestCategory("SkipWhenLiveUnitTesting")]

Schließen Sie mithilfe der folgenden Attribute eine gesamte Assembly von Live Unit Testing aus:

  • xUnit: [assembly: AssemblyTrait("Category", "SkipWhenLiveUnitTesting")]
  • NUnit: [assembly: Category("SkipWhenLiveUnitTesting")]
  • MSTest: [assembly: TestCategory("SkipWhenLiveUnitTesting")]

Anzeigen der Abdeckungsvisualisierung

Nach der Aktivierung aktualisiert Live Unit Testing alle Codezeilen im Visual Studio-Editor, um Ihnen zu zeigen, ob der Code, den Sie schreiben, durch Komponententests abgedeckt ist, und ob die Tests für diesen Code erfolgreich sind.

Die folgende Abbildung zeigt Codezeilen mit bestandenen und fehlerhaften Tests sowie Codezeilen, die nicht durch Tests abgedeckt sind. Zeilen mit einem grünen ✓ sind nur durch bestandene Tests abgedeckt. Zeilen mit einem roten „x“ sind durch mindestens einen fehlerhaften Test abgedeckt. Linien mit einem blauen ➖ sind durch keinen Test abgedeckt.

Screenshot: Code Coverage in Visual Studio.

Die Abdeckungsvisualisierung von Live Unit Testing wird sofort aktualisiert, wenn Sie Code im Code-Editor ändern. Während der Verarbeitung der Änderungen ändert sich die Visualisierung, um darauf hinzuweisen, dass die Daten nicht auf dem neuesten Stand sind. Dazu wird unterhalb der Symbole für erfolgreiche, nicht erfolgreiche und nicht abgedeckte Tests ein rundes Uhrensymbol angezeigt, wie in der folgenden Abbildung dargestellt.

Screenshot, der Code Coverage in Visual Studio mit Timersymbol zeigt.

Abrufen von Informationen über den Teststatus

Wenn Sie den Mauszeiger im Codefenster über die Symbole für erfolgreiche oder nicht erfolgreiche Tests bewegen, können Sie sehen, wie viele Tests diese Zeile betreffen. Um den Status der einzelnen Tests anzuzeigen, wählen Sie das Symbol aus.

Screenshot, der den Teststatus für ein Symbol in Visual Studio zeigt.

Neben der Angabe der Namen und Testergebnisse können Sie mithilfe der QuickInfo die Gruppe von Tests erneut ausführen oder debuggen. Wenn Sie einen oder mehrere Tests in der QuickInfo auswählen, können Sie auch nur diese Tests ausführen oder debuggen. Mit dieser Aktion können Sie Tests debuggen, ohne das Codefenster verlassen zu müssen.

Beim Debuggen wird die Programmausführung bei allen eventuell festgelegten Haltepunkten sowie zusätzlich dann angehalten, wenn der Debugger eine Assert-Methode ausführt, die ein unerwartetes Ergebnis zurückgibt.

Wenn Sie den Mauszeiger über einen nicht bestandenen Test in der QuickInfo bewegen, wird die QuickInfo erweitert und zeigt weitere Informationen zum Fehler an, wie in der folgenden Abbildung dargestellt wird. Um direkt zu einem nicht erfolgreichen Test zu wechseln, doppelklicken Sie in der QuickInfo darauf.

Screenshot, der fehlgeschlagenen QuickInfo-Informationen zu Tests in Visual Studio zeigt.

Wenn Sie zu einem nicht erfolgreichen Test wechseln, zeigt Live Unit Testing in der Methodensignatur folgende Status für die Tests an:

  • Erfolgreich (angezeigt durch einen halb vollen Glaskolben zusammen mit einem grünen ✓)
  • Nicht erfolgreich (angezeigt durch einen halb vollen Glaskolben zusammen mit einem roten 🞩)
  • Nicht an Live Unit Testing beteiligt (angezeigt durch einen halb vollen Glaskolben zusammen mit einem blauen ➖)

Nicht getestete Methoden werden nicht durch ein Symbol gekennzeichnet. Die folgende Abbildung zeigt alle vier Arten von Methoden.

Screenshot, der Testmethoden in Visual Studio mit dem Symbolen für „erfolgreich“ oder „nicht erfolgreich“ zeigt.

Diagnostizieren und Beheben von Testfehlern

Über den nicht erfolgreichen Test können Sie problemlos den Produktcode debuggen, ihn bearbeiten und die Entwicklung Ihrer Anwendung fortsetzen. Da Live Unit Testing im Hintergrund ausgeführt wird, müssen Sie Live Unit Testing beim Debuggen, Bearbeiten und Fortsetzen des Zyklus nicht beenden und neu starten.

Beispiel: Der in der obigen Abbildung dargestellte nicht bestandene Test wurde durch die falsche Annahme in der Testmethode verursacht, dass nicht alphabetische Zeichen true zurückgeben, wenn sie an die System.Char.IsLower-Methode übergeben werden. Nachdem Sie die Testmethode korrigiert haben, sollten alle Tests bestanden werden. Sie müssen Live Unit Testing nicht vorübergehend anhalten oder beenden.

Live Unit Testing-Fenster

Ähnlich wie der Test-Explorer stellt Live Unit Testing eine Schnittstelle bereit, mit der Sie Tests ausführen und debuggen sowie Testergebnisse analysieren können. Wenn Live Unit Testing aktiviert ist, wird der Status der Komponententests im Test-Explorer sofort aktualisiert. Sie müssen die Komponententests nicht explizit ausführen.

Wenn Live Unit Testing nicht aktiviert ist oder beendet wurde, zeigt Live Unit Testing den Status von Komponententests bei der letzten Testausführung an. Nachdem Sie Live Unit Testing neu gestartet haben, müssen Sie eine Änderung am Quellcode vornehmen, um die Tests nochmal auszuführen.

Sie können Live Unit Testing starten, indem Sie im Visual Studio-Menü der obersten Ebene Test>Live Unit Testing>Starten auswählen. Sie können das Fenster Live Unit Testing auch über Ansicht>Weitere Fenster>Live Unit Testing-Fenster öffnen.

Möglicherweise ist Ihnen aufgefallen, dass im Fenster Live Unit Testing einige Tests in blasser Schrift angezeigt werden. Wenn Sie Live Unit Testing beenden und neu starten, werden beispielsweise alle Tests im Fenster Live Unit Testing wie in der folgenden Abbildung gezeigt verblasst angezeigt.

Testergebnisse in blasser Schrift weisen darauf hin, dass der jeweilige Test nicht im Rahmen der letzten Ausführung von Live Unit Testing stattfand. Tests werden nur ausgeführt, wenn eine Änderung am Test oder den Abhängigkeiten des Tests erkannt wird. Wenn es keine Änderungen gibt, wird eine unnötige Ausführung der Tests vermieden. In diesem Fall ist das Testergebnis in blasser Schrift weiterhin aktuell, obwohl der Test nicht in der letzten Ausführung enthalten war.

Screenshot, der ausgeblendete Tests im Test-Explorer zeigt.

Sie können Tests, die verblasst angezeigt werden, noch mal ausführen, indem Sie eine Änderung am Code vornehmen.

Es gibt einige Unterschiede zwischen dem automatischen Ausführen und Aktualisieren der Testergebnisse durch Live Unit Testing und dem expliziten Ausführen von Tests im Test-Explorer. Zu diesen Unterschieden zählen Folgende:

  • Beim Ausführen oder Debuggen von Tests über das Test-Explorer-Fenster werden normale Binärdateien ausgeführt. Live Unit Testing führt instrumentierte Binärdateien aus.
  • Live Unit Testing erstellt keine neue Anwendungsdomäne zum Ausführen von Tests. Stattdessen werden Tests in der Standarddomäne ausgeführt. Tests, die über das Test-Explorer-Fenster ausgeführt werden, erstellen eine neue Anwendungsdomäne.
  • Live Unit Testing führt Tests in allen Testassemblys nacheinander aus. Im Fenster Test-Explorer können Sie auswählen, mehrere Tests parallel auszuführen.

Abbrechen von Live Unit Testing-Testausführungen

Live Unit Testing führt Tests immer dann aus, wenn Sie etwas am Code ändern. Wenn eine Ausführung läuft und Sie weitere Codeänderungen vornehmen, reiht Live Unit Testing eine weitere Ausführung in die Warteschlange ein, während auf den Abschluss der ersten Ausführung gewartet wird.

Sobald Sie Dateien speichern, bricht Live Unit Testing die erste Ausführung ab und plant stattdessen sofort die in die Warteschlange eingereihte Ausführung. Diese Vorgehensweise hilft bei Szenarien, in denen die erste Ausführung viel Zeit in Anspruch genommen hätte.

Siehe auch