Freigeben über


VSTest Bridge-Erweiterung

Diese Erweiterung bietet eine Kompatibilitätsebene mit VSTest, sodass die Testframeworks abhängig davon weiterhin im VSTest-Modus ausgeführt werden können (vstest.console.exe, üblicherweise dotnet test, VSTest task auf AzDo, Test-Explorers von Visual Studio und Visual Studio Code...). Diese Erweiterung wird als Teil des Microsoft.Testing.Extensions.VSTestBridge-Pakets ausgeliefert.

Wichtig

Das Paket wird mit der geschlossenen Quelle von Microsoft .NET Library und dem kostenlosen Lizenzierungsmodell ausgeliefert.

Kompatibilität mit VSTest

Der Hauptzweck dieser Erweiterung ist es, eine einfache und reibungslose Upgrade-Erfahrung für VSTest-Benutzer zu bieten, indem ein dualer Modus ermöglicht wird, in dem die neue Plattform aktiviert ist und parallel ein Kompatibilitätsmodus angeboten wird, damit die üblichen Workflows weiter funktionieren.

Runsettings-Support

Mit dieser Erweiterung können Sie eine VSTest .runsettings-Datei bereitstellen, aber nicht alle Optionen in dieser Datei werden von der Plattform aufgenommen. Nachfolgend werden die unterstützten und nicht unterstützten Einstellungen, Konfigurationsoptionen und Alternativen für die am häufigsten verwendeten VSTest-Konfigurationsoptionen beschrieben.

Wenn sie vom Testframework aktiviert ist, können Sie --settings <SETTINGS_FILE> verwenden, um die .runsettings-Datei bereitzustellen.

RunConfiguration-Element

Das RunConfiguration-Element kann folgende Elemente enthalten. Keine dieser Einstellungen wird von Microsoft.Testing.Platform beachtet:

Node Beschreibung Grund/Problemumgehung
MaxCpuCount Diese Einstellung steuert die Ebene der Parallelität auf Prozessebene. Verwenden Sie 0 (null), um die maximale Parallelität auf Prozessebene zu aktivieren. Wenn Microsoft.Testing.Platform mit MSBuild verwendet wird, wird diese Option an MSBuild ausgelagert. Wenn eine einzelne ausführbare Datei ausgeführt wird, hat diese Option keine Bedeutung für Microsoft.Testing.Platform.
ResultsDirectory Das Verzeichnis, in dem die Testergebnisse gespeichert werden. Der Pfad ist relativ zu dem Verzeichnis, das die Datei vom Typ .runsettings enthält. Verwenden Sie die Befehlszeilenoption --results-directory, um das Verzeichnis zu bestimmen, in dem die Testergebnisse platziert werden sollen. Wenn das Verzeichnis noch nicht vorhanden ist, wird es erstellt. Der Standardwert ist TestResults im Verzeichnis, das die Testanwendung enthält.
TargetFrameworkVersion Diese Einstellung definiert die Frameworkversion oder Frameworkfamilie, die zum Ausführen von Tests verwendet werden soll. Diese Option wird ignoriert. Die MSBuild-Eigenschaft <TargetFramework> oder <TargetFrameworks> bestimmt das Zielframework der Anwendung. Die Tests werden in der endgültigen Anwendung gehostet.
TargetPlatform Diese Einstellung definiert die Architektur, die zum Ausführen von Tests verwendet werden soll. <RuntimeIdentifier> bestimmt die Architektur der endgültigen Anwendung, die die Tests hostet.
TreatTestAdapterErrorsAsWarnings Unterdrückt Testadapterfehler und macht sie zu Warnungen. Mit Microsoft.Testing.Platform kann nur eine einzelne Art von Tests über eine einzelne Assembly ausgeführt werden, und wenn das Testframework oder andere Komponenten der Infrastruktur nicht geladen werden, ist dies ein nicht überspringbarer Fehler, da dies bedeutet, dass einige Tests nicht erkannt oder ausgeführt werden konnten.
TestAdaptersPaths Ein oder mehrere Pfade zu dem Verzeichnis, in dem die Testadapter gespeichert sind. Microsoft.Testing.Platform verwendet keine Testadapter und lässt dynamisches Laden von Erweiterungen nur dann zu, wenn sie Teil des Builds sind und in Program.cs registriert werden – entweder automatisch über Buildziele oder manuell.
TestCaseFilter Ein Filter zum Einschränken der auszuführenden Tests. Verwenden Sie zum Filtern von Tests die Befehlszeilenoption --filter.
TestSessionTimeout Ermöglicht Benutzern, eine Testsitzung zu beenden, wenn sie ein angegebenes Timeout überschreitet. Es gibt keine alternative Option.
DotnetHostPath Legen Sie einen benutzerdefinierten Pfad zum Dotnet-Host fest, der zum Ausführen des Testhosts verwendet wird. Microsoft.Testing.Platform führt keine zusätzliche Auflösung von dotnet durch. Es wird einzig die eigene Auflösung von dotnet selbst verwendet, was mithilfe von Umgebungsvariablen wie DOTNET_HOST_PATH gesteuert werden kann.
TreatNoTestsAsError Dient zum Beenden mit einem Exitcode ungleich null, wenn keine Tests erkannt werden. Von Microsoft.Testing.Platform wird standardmäßig ein Fehler ausgegeben, wenn in einer Testanwendung keine Tests erkannt oder ausgeführt werden. Sie können festlegen, wie viele Tests in der Assembly gefunden werden sollen, indem Sie den (standardmäßig auf „1“ festgelegten) Befehlszeilenparameter --minimum-expected-tests verwenden.

DataCollectors-Element

Microsoft.Testing.Platform verwendet keine Datensammler. Stattdessen werden In-Process- und Out-of-Process-Erweiterungen verwendet. Jede Erweiterung wird durch die jeweilige Konfigurationsdatei oder über die Befehlszeile konfiguriert.

Die wichtigsten Erweiterungen sind „Absturzabbild“ (hangdump und crashdump) und Microsoft Code Coverage.

LoggerRunSettings-Element

Protokollierungen in Microsoft.Testing.Platform werden über Befehlszeilenparameter oder über Einstellungen im Code konfiguriert.

VSTest-Filterunterstützung

Diese Erweiterung bietet auch die Möglichkeit, den VSTest-Filtermechanismus zu verwenden, um nur die Tests zu ermitteln oder auszuführen, die dem Filterausdruck entsprechen. Weitere Informationen finden Sie im Abschnitt Filteroptionsdetails oder für frameworkspezifische Details auf der Seite Ausführen selektiver Komponententests.

Wenn sie vom Testframework aktiviert ist, können Sie --filter <FILTER_EXPRESSION> verwenden.