MSTest SDK-Konfiguration

In diesem Artikel werden erweiterte Konfigurationsoptionen für MSTest.Sdk behandelt. Grundlegendes Setup und den Einstieg finden Sie unter Einführung in MSTest.

Wichtig

Standardmäßig verwendet MSTest.Sdk den MSTest runner mit MTP, einschließlich dotnet test. Dies erfordert das Ändern Ihrer CI- und lokalen CLI-Aufrufe und wirkt sich auch auf die verfügbaren Einträge der .runsettings aus. Sie können die alten Integrationen und Tools beibehalten, indem Sie zu VSTest wechseln.

MSTest.Sdk setzt EnableMSTestRunner und TestingPlatformDotnetTestSupport standardmäßig auf "true". Weitere Informationen zum Dotnet-Test und den verschiedenen Modi finden Sie unter "Testen mit dotnet"-Test.

Testen von Hilfsprogrammbibliotheken

Wenn das Projekt, das MSTest.Sdk verwendet, eine Hilfsbibliothek für Tests ist und selbst keine ausführbaren Tests enthält, sollte das Projekt <IsTestApplication>false</IsTestApplication> enthalten.

Läufer auswählen

Standardmäßig basiert MSTest SDK auf MTP, Sie können jedoch zu VSTest wechseln, indem Sie die Eigenschaft <UseVSTest>true</UseVSTest>hinzufügen.

Erweitern von MTP

Sie können die MTP-Oberfläche über eine Reihe von NuGet-Paketerweiterungen anpassen. Um diese Erfahrung zu vereinfachen und zu verbessern, führt das MSTest SDK zwei Features ein:

Microsoft.Testing.Platform Profil

Mit dem Konzept von profiles können Sie die Standardkonfigurationen und Erweiterungen auswählen, die auf Ihre Test-project angewendet werden.

Sie können das Profil mithilfe der Eigenschaft TestingExtensionsProfile auf eines der folgenden drei Profile festlegen:

  • None – Es sind keine Erweiterungen aktiviert.

  • Default – Aktiviert die empfohlenen Erweiterungen für diese Version von MSTest.SDK. Dies ist die Standardeinstellung, wenn die Eigenschaft nicht explizit festgelegt wird.

    Aktiviert die folgenden Erweiterungen:

  • AllMicrosoft– Aktiviert die Microsoft Erweiterungen, die für die allgemeine Out-of-the-Box-Verwendung ausgewählt wurden, einschließlich Erweiterungen mit einer restriktiven Lizenz. Experimentelle und nur API-Erweiterungen können dennoch explizite Opt-Ins erfordern.

    Aktiviert alle Erweiterungen aus dem Default Profil sowie die folgenden Erweiterungen:

    In MSTest.Sdk-Versionen 3.11.0 bis 4.2.x ist die Azure DevOps Berichtserweiterung nur in AllMicrosoftenthalten.

Hinweis

Die Profile verweisen auf die Berichtspakete für Azure DevOps und GitHub Actions, aber die Berichterstellung bleibt zur Laufzeit deaktiviert. Geben Sie --report-azdo an, um die Azure-DevOps-Berichterstellung zu aktivieren. Um die Berichterstellung für GitHub Actions zu aktivieren, führen Sie die Tests in GitHub Actions aus und übergeben Sie --report-gh.

Hier ist ein vollständiges Beispiel für die Verwendung des None-Profils:

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <TestingExtensionsProfile>None</TestingExtensionsProfile>
    </PropertyGroup>

</Project>
Erweiterung/profil Nichts Standard AllMicrosoft
Codeabdeckung ✔️ ✔️
Absturzabbild ✔️
Fälschungen ✔️¹
Hang-Dump ✔️
Hot Reload ✔️
HTML-Bericht ✔️
GitHub-Actions-Bericht ✔️³ ✔️³
Wiederholen. ✔️
Trx ✔️ ✔️
bericht Azure DevOps ✔️³ ✔️²

¹ MSTest.Sdk 3.7.0+ ² MSTest.Sdk 3.11.0+ ¹ MSTest.Sdk 4.3.0+

Aktivieren oder Deaktivieren von Erweiterungen

Erweiterungen können durch MSBuild-Eigenschaften mit dem Muster Enable[NugetPackageNameWithoutDots] aktiviert und deaktiviert werden.

Verwenden Sie beispielsweise die folgende auf festgelegte Eigenschaft EnableMicrosoftTestingExtensionsCrashDump, um die Absturzabbilderweiterung (NuGet-Paket true) zu aktivieren:

<Project Sdk="MSTest.Sdk/4.1.0">

<PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <EnableMicrosoftTestingExtensionsCrashDump>true</EnableMicrosoftTestingExtensionsCrashDump>
</PropertyGroup>

</Project>

Eine Liste aller verfügbaren Erweiterungen finden Sie unter MTP-Features.

Einige MTP-Erweiterungen bleiben optional und sind nicht in den Profilen Default oder AllMicrosoft enthalten:

  • Ab MSTest.Sdk 4.3 legen Sie <EnableMicrosoftTestingExtensionsJUnitReport>true</EnableMicrosoftTestingExtensionsJUnitReport> fest und übergeben dann --report-junit.
  • Ab der MSTest.Sdk 4.4-Vorschau legen Sie <EnableMicrosoftTestingExtensionsCtrfReport>true</EnableMicrosoftTestingExtensionsCtrfReport> fest und übergeben dann --report-ctrf.
  • Legen Sie fest <EnableMicrosoftTestingExtensionsOpenTelemetry>true</EnableMicrosoftTestingExtensionsOpenTelemetry>, um auf die OpenTelemetry-Erweiterung zu verweisen. Da für die Erweiterung eine API-Konfiguration erforderlich ist, registrieren Sie sie in Ihrem benutzerdefinierten Einstiegspunkt, wie in OpenTelemetry beschrieben.

Diese Erweiterungen sind nur bei MTP verfügbar.

Warnung

Überprüfen Sie unbedingt die Lizenzbedingungen für jede Erweiterung, da diese variieren können.

Aktivierte und deaktivierte Erweiterungen werden mit den Erweiterungen kombiniert, die von Ihrem ausgewählten Erweiterungsprofil bereitgestellt werden.

Dieses Eigenschaftsmuster kann verwendet werden, um zusätzlich zum impliziten Default-Profil eine zusätzliche Erweiterung zu aktivieren (wie im vorherigen CrashDumpExtension-Beispiel gezeigt).

Sie können Erweiterungen aus dem ausgewählten Profil auch deaktivieren. Deaktivieren Sie z. B. die MS Code Coverage-Erweiterung, indem Sie <EnableMicrosoftTestingExtensionsCodeCoverage>false</EnableMicrosoftTestingExtensionsCodeCoverage> festlegen:

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <EnableMicrosoftTestingExtensionsCodeCoverage>false</EnableMicrosoftTestingExtensionsCodeCoverage>
    </PropertyGroup>

</Project>

In MSTest.Sdk 4.3.0 und höher verweist das Default Profil auf die Azure DevOps Berichts- und GitHub Actions Berichtspakete. Um einen der beiden Paketverweise zu entfernen, setzen Sie <EnableMicrosoftTestingExtensionsAzureDevOpsReport>false</EnableMicrosoftTestingExtensionsAzureDevOpsReport> bzw. <EnableMicrosoftTestingExtensionsGitHubActionsReport>false</EnableMicrosoftTestingExtensionsGitHubActionsReport>. Wenn Sie die Paketverweise beibehalten, beginnt die Azure-DevOps-Berichterstellung nur, wenn Sie --report-azdo übergeben. Die GitHub-Actions-Berichterstattung beginnt nur, wenn Sie die Tests in GitHub Actions ausführen und --report-gh übergeben.

Funktionen

Neben der Auswahl des Runners und der läuferspezifischen Erweiterungen bietet MSTest.Sdk zusätzliche Funktionen, um Ihre Testerfahrung zu vereinfachen und zu verbessern.

Testen mit Aspire

Aspire ist ein dogmatischer, cloudfähiger Stapel zum Erstellen von beobachtbaren, produktionsbereiten, verteilten Anwendungen. Aspire wird über eine Sammlung von NuGet-Paketen bereitgestellt, die bestimmte cloudeigene Bedenken behandeln. Weitere Informationen finden Sie in den Aspire Dokumenten.

Hinweis

Dieses Feature ist über MSTest.Sdk 3.4.0 verfügbar.

Indem Sie die EnableAspireTesting-Eigenschaft auf true festlegen, können Sie alle Abhängigkeiten und using-Standardanweisungen, die Sie zum Testen mit Aspire und MSTest benötigen, bereitstellen.

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <EnableAspireTesting>true</EnableAspireTesting>
    </PropertyGroup>

</Project>

Testen mit Playwright

Playwright ermöglicht zuverlässige End-to-End-Tests für moderne web apps. Weitere Informationen finden Sie in der offiziellen Playwright-Dokumentation.

Hinweis

Dieses Feature ist über MSTest.Sdk 3.4.0 verfügbar.

Indem Sie die EnablePlaywright-Eigenschaft auf true festlegen, können Sie alle Abhängigkeiten und using-Standardanweisungen, die Sie zum Testen mit Playwright und MSTest benötigen, bereitstellen.

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <EnablePlaywright>true</EnablePlaywright>
    </PropertyGroup>

</Project>

Migrieren zum MSTest SDK

Beachten Sie die folgenden Schritte, die zum Migrieren zum MSTest-SDK erforderlich sind.

Aktualisieren Sie Ihr Projekt

Wenn Sie ein vorhandenes MSTest-Testprojekt zu MSTest SDK migrieren, ersetzen Sie zunächst den Eintrag Sdk="Microsoft.NET.Sdk" oben im Testprojekt durch Sdk="MSTest.Sdk"

- Sdk="Microsoft.NET.Sdk"
+ Sdk="MSTest.Sdk"

Fügen Sie die Version zu global.json hinzu:

{
    "msbuild-sdks": {
        "MSTest.Sdk": "4.1.0"
    }
}

Sie können dann mit der Vereinfachung Ihrer project beginnen.

Entfernen Sie Standardeigenschaften:

- <EnableMSTestRunner>true</EnableMSTestRunner>
- <OutputType>Exe</OutputType>
- <IsPackable>false</IsPackable>
- <IsTestProject>true</IsTestProject>

Entfernen Sie Standardpaketverweise:

- <PackageReference Include="MSTest"
- <PackageReference Include="MSTest.TestFramework"
- <PackageReference Include="MSTest.TestAdapter"
- <PackageReference Include="MSTest.Analyzers"
- <PackageReference Include="Microsoft.NET.Test.Sdk"

Schließlich können Sie basierend auf dem verwendeten Erweiterungsprofil auch einige der Microsoft.Testing.Extensions.*-Pakete entfernen.

Aktualisieren Ihrer CI

Nachdem Sie Ihre Projekte aktualisiert haben, müssen Sie ihre CI-Konfiguration aktualisieren, wenn Sie MTP (Standard) verwenden und sich darauf dotnet test verlassen, Ihre Tests auszuführen. Weitere Informationen und Hinweise zum Verständnis aller erforderlichen Änderungen finden Sie unter Integration von „dotnet test”.

Wenn Sie den VSTest-Modus von dotnet test verwenden, finden Sie hier ein Beispielupdate, wenn Sie die Aufgabe DotNetCoreCLI in Azure DevOps verwenden:

Das Standarderweiterungsprofil von MSTest.Sdk liefert die Microsoft.Testing.Extensions.TrxReport- und Microsoft.Testing.Extensions.CodeCoverage-Pakete, die für die hinzugefügten Optionen erforderlich sind. Wenn Sie das None-Profil auswählen, aktivieren Sie beide Erweiterungen oder verweisen Sie auf beide Erweiterungen, bevor Sie die Optionen verwenden.

\- task: DotNetCoreCLI@2
  inputs:
    command: 'test'
    projects: '**/**.sln'
-    arguments: '--configuration Release'
+    arguments: '--configuration Release -- --report-trx --results-directory $(Agent.TempDirectory) --coverage'

Spiegelungsquellengenerator

Wichtig

Das folgende MSTest 4.4-Verhalten ist nur in Vorschaubuilds verfügbar, bis MSTest 4.4.0 veröffentlicht wird.

MSTest 4.3 führte den Spiegelungsquellengenerator in das unabhängig versionsierte experimentelle MSTest.SourceGeneration Paket ein. Ab MSTest 4.4 hat das Paket keinen experimentellen Status mehr und verwendet die MSTest-Version.

Systemeigene AOT-Projekte enthalten automatisch den Quellgenerator. Für ein Nicht-NativeAOT-Projekt, das MSTest.Sdk verwendet, melden Sie sich mit <EnableMSTestSourceGeneration>true</EnableMSTestSourceGeneration>. MSTest.Sdk gleicht die Versionen von MSTest.SourceGeneration, MSTest.TestFramework und MSTest.TestAdapter über MSTestVersion ab.

Das SDK unterstützt auch die Quellgenerierung in wiederverwendbaren Testbibliotheken und Projekten, die die zentrale Paketverwaltung verwenden. Es liefert übereinstimmende MSTest.TestAdapter Laufzeit-Hooks und generiert die erforderlichen PackageVersion Elemente.

.NET Standard unterstützt diese Laufzeit-Hooks nicht. Wenn Sie die Quellgenerierung für ein .NET Standardziel aktivieren, meldet das SDK diesen Fehler:

MSTest-Quellgenerierung wird für .NET Standardzielframeworks nicht unterstützt, da die erforderlichen MSTest.TestAdapter-Laufzeithaken nicht verfügbar sind.

Der Quellgenerator erkennt Tests während der Kompilierung. Wenn der Generator aktiv ist, müssen Testklassen direkt deklarieren [TestClass] , anstatt ihn zu erben. Der MSTEST0069-Analyzer markiert Klassen, die auf einem geerbten [TestClass] basieren.

Ab MSTest 4.3.2 ist MSTestSourceGenMode für gekürzte und Native AOT-Projekte standardmäßig ReflectionFree. Dieser Modus verwendet generierte Metadaten und Aufrufer, wenn diese die Testform unterstützen. Bei Laufzeiten, die Reflexion unterstützen, greift MSTest bei nicht unterstützten oder fehlenden generierten Einträgen auf Reflexion zurück.

Ab MSTest 4.4 erstellt die reflexionsfreie Generierung vollständige Metadaten geerbter Attribute, einschließlich AttributeUsage und AllowMultiple. Auf MTP kann die Laufzeitermittlung und -validierung für einfache synchrone [TestMethod] und [DataRow] Methoden umgangen werden. Asynchrone Tests, benutzerdefinierte Testmethodenattribute, benutzerdefinierte DynamicDataITestDataSource-Implementierungen und mehrdeutige Testformen verwenden den Fallback-Pfad. VSTest behält auch seinen vorhandenen Pfad bei.

Der Spiegelungsfreie Modus meldet die folgenden Diagnosen:

ID Nicht unterstützte Testform
AOTSG0001 Statische Testklasse
AOTSG0002 Öffnen einer generischen Testklasse, einschließlich einer klasse, die in einem generischen Typ geschachtelt ist
AOTSG0003 Klasse, auf die generierter Code nicht zugreifen kann, einschließlich einer dateilokalen Klasse oder einer privaten oder privaten geschützten Schachtelung
AOTSG0004 Generische Testmethode
AOTSG0005 Testmethode mit einem ref, inoder out Parameter

Experimentelle Features

Die folgenden MSTest 4.3-Features sind experimentell. Ihre öffentlichen APIs können sich ändern und werden nur über experimentelle Diagnosefunktionen verfügbar gemacht. Um sich zu anmelden, bestätigen Sie die entsprechende Diagnose-ID.

Programmgesteuerte Testfilterung mit ITestFilter

Hinweis

Eingeführt in MSTest 4.3.0 (experimentell).

Mit dem experimentellen ITestFilter Erweiterungspunkt, der durch [TestFilterProviderAttribute]registriert wird, können Sie programmgesteuert entscheiden, ob jeder Test ausgeführt wird, bevor eine Testklasse geladen wird. Dies ist nützlich für benutzerdefinierte Auswahllogik, die nicht mit Befehlszeilenfiltern ausgedrückt werden kann.

Implementieren Sie ITestFilter.Filter(TestFilterContext) , um Metadaten zu prüfen, ohne die Testklasse zu laden:

public sealed class MyFilter : ITestFilter
{
    public TestFilterResult Filter(TestFilterContext context) =>
        context.DisplayName.Contains("Nightly", StringComparison.Ordinal)
            ? TestFilterResult.Run : TestFilterResult.Drop;
}

Drücken Sie die Eingabetaste TestFilterResult.Run, um den Test auszuführen, Drop, um ihn ohne Ergebnis auszulassen, oder Skip(reason), um ein Ergebnis als übersprungen zu melden. MSTest kann eine Filterinstanz gleichzeitig aufrufen, sodass Implementierungen threadsicher sein müssen. Befehlszeilen- und Test-Explorer-Filter werden vor ITestFilter angewendet, während [Ignore] erst danach ausgewertet wird.

Ab MSTest 4.4 können .NET Projekte das generische, typsichere Registrierungsformular [assembly: TestFilterProvider<MyFilter>]verwenden. Der Compiler erzwingt dann, dass MyFilterITestFilter implementiert und über einen öffentlichen parameterlosen Konstruktor verfügt. Das generische Attribut ist für .NET Framework nicht verfügbar. Wählen Sie für ein Projekt mit mehreren Zielframeworks die generische oder nicht generische Form mithilfe eines Präprozessorsymbols für das Zielframework aus.

#if NET
[assembly: TestFilterProvider<MyFilter>]
#else
[assembly: TestFilterProvider(typeof(MyFilter))]
#endif

Ab MSTest 4.4 überprüft der MSTEST0081 Analyzer das nicht generische Registrierungsformular vollständig. Für die generische Form meldet es weiterhin generische Filtertypen und Assemblies, die mehr als einen Provider registrieren.

TestRun.Current und geplante Tests

Hinweis

Eingeführt in MSTest 4.3.0 (experimentell).

Die experimentelle TestRun.Current API (aus RFC 014) macht Informationen über die aktuelle Ausführung verfügbar, einschließlich der geplanten Tests, sodass Erweiterungen und Einrichtungen prüfen können, was geplant ist.

Bekannte Einschränkungen

Die von NuGet bereitgestellten MSBuild-SDKs (einschließlich MSTest.Sdk) haben limited tooling support wenn es um das Aktualisieren ihrer Version geht, was bedeutet, dass das übliche NuGet-Update und Visual Studio UI für die Verwaltung von NuGet-Paketen nicht wie erwartet funktionieren. Sie müssen die Version in der Datei global.json und in der Projektdatei manuell aktualisieren. (Dies gilt auch, wenn Sie Dependabot aufgrund von Problemen dependabot-core#12824 und dependabot-core#8615 verwenden.)

Siehe auch

  • Last updated on