MSTest-Übersicht

MSTest, Microsoft Testing Framework, ist ein vollständig unterstütztes, open-source- und plattformübergreifendes Testframework für .NET-Anwendungen. Es ermöglicht Ihnen, Tests zu schreiben und auszuführen, und stellt Testsuiten mit Integration in Visual Studio und Visual Studio Code Test Explorers, die .NET CLI und viele CI-Pipelines bereit.

MSTest wird auf GitHub gehostet und funktioniert mit allen unterstützten .NET-Zielen.

Wichtigste Funktionen

MSTest bietet umfassende Testfunktionen:

  • Datengesteuerte Tests: Führen Sie Tests mit mehreren Eingaben mithilfe DataRowvon , CombinatorialData, DynamicDataund externen Datenquellen aus.
  • Testlebenszyklusverwaltung: Einrichten und Bereinigen auf Assembly-, Klassen- und Testebenen.
  • Parallele Ausführung: Führen Sie Tests gleichzeitig aus, um die Ausführungszeit zu reduzieren.
  • Testorganisation: Kategorisieren, Priorisieren und Filtern von Tests mit Metadatenattributen.
  • Code-Analysatoren: Erkennung häufiger Probleme und Erzwingen bewährter Methoden während der Kompilierungszeit.
  • Assertionen: Umfassende Assertionsmethoden zum Validieren von Ergebnissen.

Unterstützte Plattformen

MSTest unterstützt eine vielzahl von .NET-Plattformen und Zielframeworks. In der folgenden Tabelle sind Plattformunterstützung und besondere Aspekte zusammengefasst:

Plattform Zielframeworks Threading-Unterstützung Besondere Attribute Hinweise
.NET .NET 8+ Vollständige Parallelisierung Alle Attribute Empfohlen für neue Projekte
.NET Framework 4.6.2+ Vollständige Parallelisierung Alle Attribute Volle Unterstützung aller Merkmale
UWP UAP 10, .NET 10+ mit UWP-Tools UI-Thread UITestMethod MSTest 4.5 und MTP 2.5 unterstützen klassische und moderne UWP-Apps über das Appmodell-Sidecar von MSTest.Sdk
WinUI 3 .NET 8+ UI-Thread UITestMethod MTP unterstützt verpackte, entpackte und AppContainer-Hosts; siehe Testen von UWP- und WinUI 3-Apps mit MSTest und MTP
Windows Desktop-Benutzeroberflächenautomatisierung .NET 8+ Windows-Ziel STA STATestClass MSTest 4.5 Vorschau kann nicht paketierte Win32-, Windows Forms- und WPF-Apps starten und ein Fenster über Windows Benutzeroberflächenautomatisierung verfügbar machen
Native AOT .NET 8+ Vollständige Parallelisierung Die meisten Attribute Eingeschränkter Funktionsumfang; siehe natives AOT-Beispiel
Browser-WebAssembly .NET 10+ benutzerdefinierter Host Mit nur einem Thread Limited MTP-Ausführungsunterstützung beginnt mit MSTest 4.4
WASI WebAssembly .NET 10+ benutzerdefinierter Host Mit nur einem Thread Limited MTP-Ausführungsunterstützung beginnt mit MSTest 4.4

Plattformspezifische Überlegungen

UWP-Tests

UWP-Tests werden im UWP-App-Container ausgeführt und erfordern den UI-Thread für viele Vorgänge:

[TestClass]
public class UwpTests
{
    [UITestMethod]
    public void TestUwpControl()
    {
        // Test runs on UI thread
        var button = new Button();
        Assert.IsNotNull(button);
    }
}

Verwenden Sie ab MSTest 4.5 und MTP 2.5 MSTest.Sdk, um klassische UWP- und moderne .NET UWP-Tests über MTP auszuführen. Ein Full-Trust-Sidecar registriert und aktiviert das Paket, autorisiert die exakte Paket-SID der App für die MTP-Kommunikation und kopiert Ergebnisartefakte aus dem Paketspeicher.

Moderne UWP erfordert .NET 10 UseUwpund die Visual Studio UWP-Buildtoolkette. Die klassische UWP behält ihre bisherige uap10.0 Projektstruktur bei. Vollständige Konfigurationen finden Sie im modernen UWP-Beispiel und klassischen UWP-Beispiel.

WinUI 3-Testen

WinUI 3-Tests erfordern auch ui-Threadzugriff zum Testen visueller Komponenten:

[TestClass]
public class WinUITests
{
    [UITestMethod]
    public void TestWinUIControl()
    {
        // Test runs on UI thread
        var window = new MainWindow();
        Assert.IsNotNull(window);
    }
}

MTP unterstützt verpackte Full-Trust-, nicht verpackte und AppContainer-konfigurierte WinUI 3-Testanwendungen. MSTest.Sdk startet nicht paketierte Apps direkt und verwendet sein App-Model-Sidecar, um paketierte Apps zu registrieren und zu aktivieren.

AppContainer-Unterstützung erfordert MSTest 4.5 und MTP 2.5 oder höher. VSTest unterstützt nicht entpackte WinUI 3. Ausführliche Informationen finden Sie unter Testen von UWP- und WinUI 3-Apps mit MSTest und MTP.

Windows Desktop-Benutzeroberflächenautomatisierung

Das MSTest.Windows.UIAutomation Paket integriert die MSTest-Lebenszyklusverwaltung in Windows Benutzeroberflächenautomatisierung für entpackte Win32-, Windows Forms- und WPF-Anwendungen. Informationen zu Einrichtung, Einschränkungen und den Basisklassen WindowTest und ApplicationTest finden Sie unter Testen von Windows-Desktop-Apps mit MSTest Benutzeroberflächenautomatisierung.

Natives AOT

Die native AOT-Kompilierung wird aufgrund reduzierter Spiegelungsfunktionen mit einigen Einschränkungen unterstützt. Verwenden Sie nach Möglichkeit Quellgeneratoren, und testen Sie Ihre AOT-Szenarien mit dem NativeAotRunner-Beispiel.

Browser und WASI WebAssembly

MSTest 4.4 unterstützt benutzerdefinierte .NET 10-Browser oder WASI WebAssembly-Hosts. Um Tests aus einer referenzierten MSTest-Assembly auszuführen, rufen Sie AddMSTest auf. Setzen Sie im Hostprojekt EnableMSTestRunner auf true und GenerateTestingPlatformEntryPoint auf false. Halten Sie die Versionen der MSTest- und MTP-Pakete aufeinander abgestimmt.

In einer WebAssembly-Runtime mit nur einem Thread kann MSTest einen Test, dessen Zeitlimit überschritten wurde, nicht zwangsweise unterbrechen. Debugger-Wartezeit wird im Browser oder WASI nicht unterstützt, und der Browser unterstützt keine Debuggerstartoptionen.

MTP kann TRX-Daten streamen und Artefakte von Test- und Sitzungsdateien über das WebAssembly-virtuelle Dateisystem und den Artefaktkanal des Hosts melden. Azure DevOps Veröffentlichung funktioniert nur, wenn der Host den unterstützten HTTP-Zugriff und die erforderliche Pipelineauthentifizierung bereitstellt. Diese Features gewähren keinen uneingeschränkten Hostdateisystem- oder Netzwerkzugriff.

Einen vollständigen Browserhost finden Sie im BrowserPlayground-Beispiel.

STA-Threading-Unterstützung

Für Windows COM-Interop-Szenarien stellt MSTest die Attribute STATestClass und STATestMethod bereit, um Tests in einem Einzel-Thread-Apartment auszuführen. Ausführliche Informationen zum STA-Threading, einschließlich asynchroner Fortsetzungsunterstützung mit UseSTASynchronizationContext, finden Sie unter Threadingattribute.

Testläufer

MSTest unterstützt zwei Testausführungsplattformen:

  • Microsoft.Testing.Platform (MTP):Die moderne, empfohlene Testplattform mit verbesserter Leistung und Erweiterbarkeit.
  • VSTest: Die ursprüngliche und Standardtestplattform für .NET.

Für neue Projekte empfehlen wir die Verwendung von MTP mit MSTest.Sdk.

MSTest-Supportrichtlinie

Seit v3.0.0 folgt MSTest strikt der semantischen Versionsverwaltung.

Das MSTest-Team unterstützt nur die neueste veröffentlichte Version und empfiehlt benutzern dringend, immer auf die neueste Version zu aktualisieren, um von Verbesserungen und Sicherheitspatches zu profitieren. Vorschauversionen werden von Microsoft nicht unterstützt, werden aber vor der endgültigen Version für öffentliche Tests angeboten.

Versionsverlauf

MSTest hat sich in den Hauptversionen erheblich entwickelt:

  • MSTest v1: Das ursprüngliche Visual Studio-Testframework
  • MSTest v2: Erste Open-Source-Version mit plattformübergreifender Unterstützung
  • MSTest v3: Moderne Neuschreibung mit verbesserter Architektur und Features
  • MSTest v4: Aktuelle Version mit erweiterten Features

Note

MSTest 4.5 wird ab Oktober 2026 entwickelt. Features, die in MSTest 4.5 eingeführt wurden, erfordern einen Vorschaubuild, bis Version 4.5.0 veröffentlicht wird.

Ausführliche Informationen zu allen Versionen finden Sie im MSTest-Änderungsprotokoll.

Wenn Sie ein Upgrade von einer älteren Version durchführen, lesen Sie die Migrationshandbücher:

Bahnbrechende Änderungen

Das MSTest-Team überprüft sorgfältig und minimiert Änderungen, die bestehende Funktionalitäten beeinträchtigen. Wenn Breaking Changes erforderlich sind, verwendet das Team GitHub-Ankündigungen und Breaking-Change-Labels für Issues, um die Community frühzeitig zu informieren, sodass Benutzer Zeit haben, Feedback zu geben und Bedenken zu äußern, bevor die Änderungen eingeführt werden.

Nächste Schritte