Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Während Sie eine Anwendung entwickeln, führt Live Unit Testing automatisch alle betroffenen Komponententests im Hintergrund aus und stellt die Ergebnisse und codeabdeckung in Echtzeit dar. Wenn Sie Ihren Code ändern, gibt Live Unit Testing Feedback darüber, wie Sich Ihre Änderungen auf vorhandene Tests auswirken und ob der von Ihnen hinzugefügte neue Code von mindestens einem vorhandenen Test abgedeckt wird. 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. Die Verwendung beibehaltener Daten ermöglicht live Unit Testing, eine bessere Leistung zu bieten, während Ihre Tests dynamisch als Reaktion auf Codeänderungen ausgeführt werden.
Live Unit Testing ist nur in der Enterprise Edition von Visual Studio für Projekte verfügbar, die auf .NET Core oder .NET Framework abzielen.
Unterstützte Testframeworks
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 wird ebenfalls angezeigt. Die Komponententestframeworks sind alle über NuGet.org verfügbar.
| Test-Framework | Mindestversion des Visual Studio-Adapters | Framework-Mindestversion |
|---|---|---|
| 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-Vorschau | MSTest.TestFramework 1.0.5-Vorschau |
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.
In einigen Fällen müssen Sie die NuGet-Pakete, auf die von einem Projekt verwiesen wird, explizit wiederherstellen, damit Live Unit Testing funktioniert. Sie haben zwei Möglichkeiten:
- Stellen Sie die Wiederherstellung durch einen expliziten Build der Lösung her. >"Projektmappe bereinigen" im Visual Studio-Menü der obersten Ebene aus.
- Stellen Sie Pakete in der Lösung wieder her. Klicken Sie mit der rechten Maustaste auf die Lösung, und wählen Sie "NuGet-Pakete wiederherstellen" aus.
Konfigurieren
Beim ersten Starten von Live Unit Testing für eine Lösung können Sie mit einem Setup-Assistenten konfigurieren, wie Live Unit Testing Tests erstellen und ausführen soll.
Wenn Live Unit Testing deaktiviert ist, können Sie den Setup-Assistenten auch öffnen, indem Sie zu Test>Live Unit Testing>Live Unit Testing für die Lösung konfigurieren gehen.
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 eine Testausführung aus und meldet die neueste Codeabdeckung.
Das Erste, was Sie mithilfe des Assistenten konfigurieren sollten, ist, wo die Dateien kopiert werden sollen: von welchem Ort und an welchen Zielort.
Repositorystamm
Der Repositorystamm gibt den Ordner an, der kopiert wird, um den Live Unit Testing-Arbeitsbereich zu erstellen. Es sollte der Stammordner des Repositorys sein, d. h. er sollte alle Quellen, Binärdateien und Tools enthalten. In Fällen, in denen die Lösungsdatei nicht unter dem Repositorystamm vorhanden ist, muss der Repositorystamm möglicherweise geändert werden.
Arbeitsbereichsstamm
Der Arbeitsbereichstamm 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 das Root-Verzeichnis unter Ihrem Home-Verzeichnis erstellt. Wenn Sie Ihr Repository normalerweise unter Laufwerk C erstellen müssen, könnte der Arbeitsbereichsstamm jedoch an etwas wie C:\lut\Repo angepasst werden.
Angeben der ausgeschlossenen Dateien
Nicht alle Dateien sollten in den Live Unit Testing-Arbeitsbereich kopiert werden. Alle Artefakte, die während des Builds generiert werden, sollten vom Kopieren ausgeschlossen werden, damit die regulären Builds die Live Unit Testing-Builds nicht beeinträchtigen. Außerdem sollte der reguläre nuget restore Befehl den Befehl "Live Unit Testing nuget restore " nicht beeinträchtigen.
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 Arbeitsbereich "Live Unit Testing" kopiert.
Bei komplexeren Repositories müssen Sie möglicherweise Ihre eigene Ignore-Datei angeben. Wählen Sie im Assistenten die Option "<Benutzerdefiniert>" aus. Nachdem Sie „Weiter“ ausgewählt haben, erscheint der Inhalt einer benutzerdefinierten Ausschlussdatei, die von Live Unit Testing erstellt wird, nachdem der Assistent abgeschlossen ist. Es ist die Lutignore-Datei .
Hinweis
Für einige Git-Repositorys ist eine benutzerdefinierte Lutignore-Datei erforderlich, da es möglich ist, Dateien im Git-Repository zu überprüfen, 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.
Lutignore-Dateistruktur
Die Lutignore-Datei verwendet das gleiche Format wie eine Gitignore-Datei . Sie sollte Regeln enthalten, die den Ordnern oder Dateien entsprechen, die während des Builds generiert wurden, damit sie nicht in den Arbeitsbereich kopiert werden. Für die meisten 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 Ignorieren-Datei stattdessen diesen Ordner auflisten:
[Aa]rtifacts/
# WILL NOT COPY THE ARTIFACTS FOLDER TO THE LIVE UNIT TESTING WORKSPACE
Wenn Ihr Repository einige andere Tools im Buildordner enthält, sollten diese Tools in der Gruppe der übereinstimmenden Muster 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 Konfigurationsseite des Assistenten konfigurieren Sie die Buildoptionen.
- Generieren von PDBs: Um den Build zu beschleunigen, generiert Live Unit Testing während builds keine PDBs. Mit diesen Symboldateien können Sie zu den Stacktraces wechseln, wenn Fehlermeldungen in Tests auftreten.
- Erstellen mit mehreren CPU-Kernen: Standardmäßig führt Live Unit Testing Builds mit mehreren CPU-Kernen durch, wodurch die Buildzeiten verbessert werden. Wenn ihr Computer verlangsamt oder ihre Lösung nicht mit mehreren Prozessoren erstellt werden kann, wählen Sie diese Option nicht aus.
Testausführungsoptionen
Im letzten Teil der Konfigurationsseite des Assistenten richten Sie die Testausführungsoptionen ein:
- Testfall-Timeout: Einige der Tests können länger dauern, bis sie abgeschlossen sind. Das Festlegen dieses Felds führt automatisch zum Abbruch der Ausführungen, wenn einer der Tests eine bestimmte Zeitdauer überschreitet. Die Tests können automatisch abgebrochen werden.
- Verwenden Sie mehrere Prozessoren: Standardmäßig versucht Live Unit Testing, mehrere Prozessoren zu verwenden, um die Ausführungsleistung zu beschleunigen. Wenn ihr Computer verlangsamt oder ihre Lösung keine Tests parallel ausführen kann, wählen Sie diese Option nicht aus. Diese Szenarien können beispielsweise auftreten, wenn mehrere Tests versuchen, aus denselben Dateipfaden zu schreiben/zu lesen.
Weitere Konfiguration
Konfigurieren Sie Live Unit Testing, indem Sie auf der Visual Studio-Menüleiste auf oberster Ebene "Extrasoptionen>" auswählen.
Erweitern Sie im Bereich Optionen den Abschnitt Alle Einstellungen>Test>Live-Einheitentests.
Erweitern Sie im Dialogfeld "Optionen " den Abschnitt " Live Unit Testing>General ".
Nachdem Live Unit Testing aktiviert wurde (siehe Start, Pause und Beenden von Live Unit Testing), können Sie die Optionen erneut öffnen, indem Sie "Testoptionen für>>.
Zu den konfigurierbaren Optionen gehören:
Gibt an, ob live Unit Testing angehalten wird, wenn eine Lösung erstellt und gedebuggt wird.
Gibt an, ob live Unit Testing angehalten wird, wenn die Akkuleistung eines Systems unter einen angegebenen Schwellenwert fällt.
Die Möglichkeit, alle gespeicherten Daten zu löschen. Diese Funktion ist nützlich, wenn Live Unit Testing sich auf unvorhersehbare oder unerwartete Weise verhält und darauf hinweist, dass die gespeicherten Daten beschädigt sein könnten.
Die maximale Menge an Arbeitsspeicher, den Live Unit Testing-Prozesse nutzen können.
Die Ebene der Informationen, die in das Ausgabefenster für Live-Komponententests geschrieben wurden.
Optionen umfassen keine Protokollierung (Keine), fehlermeldungen nur (Fehler), Fehler- und Informationsmeldungen (Info, Standard) oder alle Details (Ausführlich).
Sie können auch eine ausführliche Ausgabe im Fenster "Live Unit Testing Output" anzeigen, indem Sie einer Umgebungsvariable auf Benutzerebene den Wert 1 zuweisen. Starten Sie dann Visual Studio neu.
Wenn Sie detaillierte MSBuild-Protokollmeldungen von Live Unit Testing in einer Datei erfassen möchten, legen Sie die
LiveUnitTesting_BuildLogUmgebungsvariable auf Benutzerebene auf den Namen der Datei fest, die das Protokoll enthalten soll.
Anpassen Ihres Builds für Live-Komponententests
Für komplexere Lösungen kann es erforderlich sein, den Build weiter anzupassen. Es kann z. B. nicht erforderlich sein, Übersetzungsdateien während der Testausführung zu erstellen. Um Ihre Builds zu beschleunigen, können Sie den Übersetzungsdateibuild mit Live Unit Testing deaktivieren. Sie können dies tun, indem Sie die Projektdateien bearbeiten.
Hinzufügen von Außerkraftsetzungen für Live-Komponententests
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 oder .targets-Dateien Code hinzufügen, der auf die BuildingForLiveUnitTesting Eigenschaft überprüft und benutzerdefinierte Schritte vor/nach dem Build ausführt.
Sie können z. B. das folgende Beispiel schreiben, um ein weiteres Ziel hinzuzufügen, das nur für Live Unit-Tests ausgeführt wird:
<Target Name="GenerateNuGetPackages" BeforeTargets="AfterBuild" Condition="'$(BuildingForLiveUnitTesting)' == 'true'">
<Exec Command='"$(MSBuildThisFileDirectory)..\tools\GenPac" '/>
</Target>
Sie können die BuildingForLiveUnitTesting Eigenschaft verwenden, um einige Aufgaben zu deaktivieren, die nicht für Testbuilds ausgeführt werden sollten. Beispielsweise setzt Live Unit Testing <RunAnalyzers>false</RunAnalyzers> zur Deaktivierung von Analyzern für Tests ein.
Testabhängigkeiten für Live-Komponententests
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. Mit dieser Anordnung können Builds auftreten, während die Tests ausgeführt werden, aber nicht alle Dateien aus dem Buildordner werden in den Testordner kopiert.
In der Regel fügen Sie die Testabhängigkeiten aus einem von zwei Gründen hinzu:
- Ihre Tests hängen von Dateien unter dem Quellbaum ab. Beispielsweise untersuchen die Tests den Inhalt der RESX-Dateien oder lesen möglicherweise einige Konfigurationsdateien.
- Ihre Tests hängen von einigen Bibliotheken ab, auf die verwiesen wird. Beispielsweise führt ein Test eine ausführbare Datei aus, die als Abhängigkeit erstellt wurde.
Hinweis
Testabhängigkeiten müssen innerhalb des Verzeichnisses vorhanden sein, das im Setup-Assistenten als Repository-Root 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, um einen Test auszuführen. Sie müssen diese Dateien explizit angeben, indem Sie die LiveUnitTestingTestDependency Eigenschaft verwenden, wenn sie für eine Testausführung erforderlich sind. Nehmen wir beispielsweise an, dass wir das folgende Layout haben:
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 hinzu:test_project.csproj
<LiveUnitTestingTestDependency Include=”$(RepoRoot)/Src/ConsoleUtility” />
<LiveUnitTestingTestDependency Include=”$(RepoRoot)/Artifacts/ConsoleUtility/net472/$(Configuration)/</LiveUnitTestingTestDependency” />
Starten, Anhalten und Beenden
Um Live Unit-Tests zu aktivieren, wählen Sie im Visual Studio-Menü der obersten Ebene die Option "Test>Live-Einheitstest>Start" aus. Wenn Live Unit Testing aktiviert ist, ändern sich die optionen, die im Menü " Live Unit Testing " verfügbar sind, von einem einzelnen Element, " Start", zu "Anhalten " und "Beenden":
Pausieren setzt Live-Einheitentests vorübergehend aus.
Wenn Live Unit Testing angehalten wird, wird die Abdeckungsvisualisierung nicht im Editor 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 erledigt die notwendige Arbeit, um alle Bearbeitungen zu erfassen, die während der Pause vorgenommen wurden, und aktualisiert die Glyphen entsprechend.
Beenden Sie das Live Unit Testing vollständig. Live Unit Testing verwirft alle Daten, die sie gesammelt haben.
Wenn Sie Live Unit Testing in einer Lösung starten, die kein Unit-Test-Projekt enthält, werden die Optionen Anhalten und Beenden im Menü Live Unit Testing angezeigt, aber Live Unit Testing wird nicht gestartet. Im Ausgabefenster wird eine Meldung angezeigt, die beginnt: "Es werden keine unterstützten Testadapter von dieser Lösung referenziert...".
Sie können das Testen von Live-Komponenten jederzeit vorübergehend anhalten oder vollständig beenden. Sie sollten diese Aktionen möglicherweise ausführen, z. B. wenn Sie sich mitten im Refactoring befinden und wissen, dass Ihre Tests für eine Weile fehlschlagen werden.
Einschließen und Ausschließen von Testprojekten und Testmethoden
Wenn Sie Live Unit Testing starten, wird das Toolfenster "Live Unit Testing" angezeigt und fordert Sie auf, die Gruppe der Tests auszuwählen, die sie von Live Unit Testing testen möchten.
Für kleinere Lösungen, bei denen die Komponententests sehr wenig Zeit in Anspruch nehmen, wählen Sie "Alle Tests einschließen" aus, wodurch Live Unit Testing alle Tests ausführt.
Für größere Lösungen mit vielen Testprojekten können Sie steuern, welche Projekte und individuellen Methoden in einem Projekt an Live Unit Testing teilnehmen, indem Sie die Wiedergabeliste bearbeiten. Wenn Sie beispielsweise über eine Lösung mit Hunderten von Testprojekten verfügen, können Sie eine gezielte Gruppe von Testprojekten auswählen, die an Live Unit Testing teilnehmen sollen.
Sie wählen aus, welche Live-Komponententests ausgeführt werden sollen, indem Sie eine Wiedergabeliste für Liveeinheitstests bearbeiten, eine Funktion, die genau wie Wiedergabelisten im Test-Explorer funktioniert.
Es gibt mehrere Möglichkeiten zum Bearbeiten der Wiedergabeliste für Live-Komponententests:
- Toolfenster "Live Unit Testing"
- Das Code-Editor-Fenster
- Lösungs-Explorer
- Programmatisch im Testcode
Live Unit Testing speichert den Include-/Ausschlussstatus als Benutzereinstellung und merkt sich, wenn eine Lösung geschlossen und erneut geöffnet wird.
Toolfenster "Live Unit Testing"
Sie können den Wiedergabelisten-Editor für die Registerkarte "Live Unit Testing" verwenden, um Projekte, Namespaces oder Klassen aus der Ausführung einzuschließen oder auszuschließen. Wählen Sie im Toolfenster " Wiedergabeliste bearbeiten" aus.
Sie können die Strukturansichtselemente auswählen oder löschen, um Tests einzuschließen oder auszuschließen. Wenn Sie z. B. einen einzelnen Test überprüfen, führt Live Unit Testing diese bei Änderungen aus. Wenn Sie eine Klasse auswählen, werden alle Tests in dieser Klasse ausgeführt, und alle neuen Tests, die dieser Klasse hinzugefügt wurden, werden ebenfalls ausgeführt.
Das Code-Editor-Fenster
Sie können das Code-Editor-Fenster verwenden, um einzelne Testmethoden einzuschließen oder auszuschließen. Klicken Sie im Code-Editor-Fenster mit der rechten Maustaste auf die Signatur oder den Textkörper der Testmethode, und wählen Sie eine der folgenden Optionen aus:
- Live-Komponententests>Ausgewählte Methode< einschließen >
- Live-Komponententests>Ausgewählte Methode< ausschließen >
- Live Unit Testing>Alle Methoden außer der <ausgewählten Methode> ausschließen
Lösungs-Explorer
Führen Sie die folgenden Schritte aus, nachdem live Unit Testing gestartet wurde, um die einzelnen Projekte in Komponententests auszuwählen:
- Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf die Projektmappe, und wählen Sie "Live Unit Testing>Exclude" aus, um die gesamte Lösung auszuschließen.
- Klicken Sie mit der rechten Maustaste auf jedes Testprojekt, das Sie in die Tests aufnehmen möchten, und wählen Sie "Live Unit Testing>Include" aus.
Programmatisch im Testcode
Sie können das ExcludeFromCodeCoverageAttribute-Attribut programmatisch anwenden, um die Berichterstattung über die Abdeckung von Methoden, Klassen oder Strukturen in Live Unit Testing auszuschließen.
Verwenden Sie die folgenden Attribute, um einzelne Methoden von Live Unit Testing auszuschließen:
-
xUnit:
[Trait("Category", "SkipWhenLiveUnitTesting")] -
NUnit:
[Category("SkipWhenLiveUnitTesting")] -
MSTest:
[TestCategory("SkipWhenLiveUnitTesting")]
Verwenden Sie die folgenden Attribute, um eine vollständige Assembly von Tests aus Live Unit Testing auszuschließen:
-
xUnit:
[assembly: AssemblyTrait("Category", "SkipWhenLiveUnitTesting")] -
NUnit:
[assembly: Category("SkipWhenLiveUnitTesting")] -
MSTest:
[assembly: TestCategory("SkipWhenLiveUnitTesting")]
Abdeckungsvisualisierung ansehen
Nachdem Live Unit Testing aktiviert wurde, wird jede Codezeile im Visual Studio-Editor aktualisiert, um ihnen zu zeigen, ob der geschriebene Code von Komponententests abgedeckt ist und ob die Tests, die sie abdecken, bestanden werden.
Die folgende Abbildung zeigt Codezeilen mit bestandenen und fehlerhaften Tests sowie Codezeilen, die nicht von Tests abgedeckt werden. Linien mit einem grünen "✓" werden nur durch bestandene Tests abgedeckt. Linien mit einem roten "x" sind durch einen oder mehrere fehlgeschlagene Tests abgedeckt. Linien mit einem blauen "➖" werden von keinem Test abgedeckt.
Live Unit Testing-Abdeckungsvisualisierung wird sofort aktualisiert, wenn Sie Code im Code-Editor ändern. Bei der Bearbeitung der Änderungen wird die Visualisierung so angepasst, dass sie anzeigt, dass die Daten veraltet sind, indem ein rundes Timer-Bild unterhalb der Symbole für bestanden, fehlgeschlagen und nicht abgedeckt hinzugefügt wird, wie die folgende Abbildung zeigt.
Abrufen von Informationen zum Teststatus
Wenn Sie im Codefenster auf das übergebene oder fehlgeschlagene Symbol zeigen, können Sie sehen, wie viele Tests diese Zeile erreicht haben. Um den Status der einzelnen Tests anzuzeigen, wählen Sie das Symbol aus.
Zusätzlich zur Angabe der Namen und Ergebnisse von Tests können Sie mit dem Tooltip den Testsatz erneut ausführen oder debuggen. Wenn Sie einen oder mehrere der Tests im Tooltip auswählen, können Sie auch nur diese Tests ausführen oder debuggen. Mit dieser Aktion können Sie Ihre Tests debuggen, ohne das Codefenster verlassen zu müssen.
Wenn Sie debuggen, wird die Programmausführung pausiert, zusätzlich zur Beobachtung der möglicherweise bereits gesetzten Haltepunkte, wenn der Debugger eine Assert-Methode ausführt, die ein unerwartetes Ergebnis zurückgibt.
Wenn Sie mit der Maus auf einen fehlgeschlagenen Test im Tooltip zeigen, wird dieser erweitert, um zusätzliche Informationen zum Fehler anzuzeigen, wie in der folgenden Abbildung dargestellt. Um direkt zu einem fehlgeschlagenen Test zu wechseln, doppelklicken Sie in der QuickInfo darauf.
Wenn Sie zum fehlgeschlagenen Test wechseln, zeigt Live Unit Testing visuell in der Methodensignatur die Tests an, die folgendes haben:
- Übergeben (angegeben durch einen halbvoller Beaker zusammen mit einem grünen "⁄").
- Fehlgeschlagen (angegeben durch einen halbvollen Becher zusammen mit einem roten "🞩").
- Sind nicht an Live Unit Testing beteiligt (angegeben durch einen halbvollen Beaker zusammen mit einem blauen "➖").
Nicht getestete Methoden werden nicht mit einem Symbol identifiziert. Die folgende Abbildung zeigt alle vier Methodentypen.
Diagnostizieren und Beheben von Testfehlern
Aus dem fehlgeschlagenen Test können Sie den Produktcode ganz einfach debuggen, Änderungen vornehmen und die Entwicklung Der Anwendung fortsetzen. Da Live Unit Testing im Hintergrund ausgeführt wird, müssen Sie während des Debug-, Bearbeitungs- und Fortsetzungszyklus keine Live Unit-Tests beenden und neu starten.
Beispielsweise wurde der im vorherigen Bild gezeigte Testfehler durch eine falsche Annahme in der Testmethode verursacht, dass nichtalphabetische Zeichen true zurückgeben, wenn sie an System.Char.IsLower übergeben werden. Nachdem Sie die Testmethode korrigiert haben, sollten alle Tests bestanden werden. Sie müssen live Unit Testing nicht anhalten oder beenden.
Live Unit Testing-Fenster
Live Unit Testing, ähnlich dem Test-Explorer, bietet eine Schnittstelle, mit der Sie Tests ausführen und debuggen und Testergebnisse analysieren können. Wenn Live Unit Testing aktiviert ist, wird der Status von Komponententests im Test-Explorer sofort aktualisiert. Sie müssen die Komponententests nicht explizit ausführen.
Wenn Live Unit Testing nicht aktiviert oder beendet ist, zeigt Live Unit Testing den Status der Komponententests an, wenn ein Test das letzte Mal ausgeführt wurde. Nach dem Neustart von Live Unit Testing ist eine Quellcodeänderung erforderlich, um die Tests erneut durchzuführen.
Sie können Live-Einheitstests starten, indem Sie im obersten Menü von Visual Studio Test>Live-Einheitstests>Starten auswählen. Sie können auch das Fenster "Live Unit Testing" öffnen, indem Sie auf Ansicht>Andere Fenster>Live Unit Testing-Fenster anzeigen.
Möglicherweise stellen Sie im Live Unit Testing-Fenster fest, dass einige Tests ausgeblendet sind. Wenn Sie beispielsweise Live Unit Testing beenden und neu starten, blendet das Fenster "Live Unit Testing " alle Tests aus, wie die folgende Abbildung zeigt.
Ausgeblendete Testergebnisse deuten darauf hin, dass der Test nicht Teil der neuesten Live-Einheitentest-Ausführung war. Tests werden nur ausgeführt, wenn eine Änderung am Test oder die Abhängigkeiten des Tests erkannt werden. Wenn keine Änderung vorhanden ist, wird die Ausführung des Tests unnötig vermieden. In diesem Fall ist das ausgegraute Testergebnis immer noch "auf dem neuesten Stand", obwohl es nicht Teil der neuesten Testrunde war.
Sie können beliebige Tests erneut ausführen, die blass angezeigt werden, indem Sie eine Codeänderung vornehmen.
Es gibt einige Unterschiede zwischen dem automatischen Ausführen und Aktualisieren von Testergebnissen und der expliziten Ausführung von Tests aus dem Test-Explorer. Zu diesen Unterschieden gehören:
- Das Ausführen oder Debuggen von Tests aus dem Fenster " Test-Explorer " führt normale Binärdateien aus. 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 aus der Standarddomäne ausgeführt. Im Fenster "Test-Explorer " werden Tests ausgeführt, um eine neue Anwendungsdomäne zu erstellen.
- Live Unit Testing führt Tests in jeder Testassembly sequenziell aus. Im Fenster "Test-Explorer " können Sie mehrere Tests parallel ausführen.
Live-Unit-Testläufe abbrechen
Live Unit Testing führt tests immer dann aus, wenn Sie Codeänderungen vornehmen. Wenn eine Ausführung ausgeführt wird und Sie weitere Codeänderungen vornehmen, führt Live Unit Testing eine weitere Ausführung in die Warteschlange ein, während sie auf den Abschluss der ersten Ausführung wartet.
Immer wenn Sie Dateien speichern, bricht Live Unit Testing die erste Ausführung ab und plant stattdessen sofort die in die Warteschlange eingereihte Ausführung. Dieser Prozess hilft bei Szenarien, in denen die erste Ausführung viel Zeit in Anspruch genommen hätte.