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 , 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 9+ mit UAP UI-Thread UITestMethod Verwenden Sie VSTest. Moderne .NET UWP erfordert <UseUwp>true</UseUwp>; siehe UWP-Beispiel
WinUI 3 .NET 8+ UI-Thread UITestMethod Erfordert Windows App SDK; siehe Testen von WinUI 3-Apps mit MSTest und MTP
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 Benutzerdefinierte Microsoft. Der Test.Platform-Hostsupport 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 VSTest für klassische UWP und moderne .NET UWP, da beide in einem AppContainer ausgeführt werden. Ein modernes .NET UWP-Setup finden Sie im BlankUwpNet9App-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);
    }
}

Informationen zum Konfigurieren von entpackten oder verpackten WinUI 3-Tests mit voll vertrauenswürdigen WinUI 3-Tests finden Sie unter Testen von WinUI 3-Apps mit MSTest und MTP.

Ab MSTest 4.4 Microsoft. Testing.Platform unterstützt auch entpackte WinUI-Testanwendungen. VSTest unterstützt dieses Szenario nicht. Details zum Setup finden Sie im entpackten WinUI-Beispiel.

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-WebAssembly

Ab MSTest 4.4 kann ein benutzerdefinierter .NET 10-BrowserwebAssembly-Host aufrufenAddMSTest, um Tests aus einer referenzierten MSTest-Assembly auszuführen. Legen Sie im Hostprojekt fest trueGenerateTestingPlatformEntryPointfalse, dass EnableMSTestRunner der benutzerdefinierte Host dem Einstiegspunkt der Anwendung gehört. Behalten Sie msTest und Microsoft bei. Test.Platform-Paketversionen ausgerichtet.

Bei einer Singlethread-WebAssembly-Laufzeit kann MSTest timedout-Tests nicht unterbrechen, und Die Startoptionen des Debuggers werden nicht unterstützt. Einen vollständigen Host 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.4 wird ab August 2026 entwickelt. Features, die in MSTest 4.4 eingeführt wurden, erfordern einen Vorschaubuild, bis Version 4.4.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

  • Last updated on