Freigeben über

Migrieren von MSTest v3 zu v4

Die stabile Version MSTest v4 ist jetzt verfügbar. In diesem Migrationshandbuch erfahren Sie, was sich in MSTest v4 geändert hat und wie Sie zu dieser Version migrieren können.

Note

Im Allgemeinen ist MSTest v4 nicht binär kompatibel mit MSTest v3. Jede mit v3 kompilierte Bibliothek muss mit v4 neu kompiliert werden.

Breaking Changes in der Quelle

Dies sind fehlerhafte Änderungen, die dazu führen können, dass Ihre Testprojekte nicht kompiliert werden.

TestMethodAttribute Breaking Changes

Ändern Sie TestMethodAttribute.Execute zu TestMethodAttribute.ExecuteAsync

Wenn Sie Ihre eigene TestMethodAttribute implementieren, müssen Sie die Execute-Überschreibung in ExecuteAsync ändern. Diese Änderung wurde vorgenommen, um langjährige Deadlock-Fehler zu beheben, die durch die synchrone Blockierungsnatur der API verursacht werden.

Beispiel: Wenn Sie zuvor folgendes hatten:

public sealed class MyTestMethodAttribute : TestMethodAttribute
{
    public override TestResult[] Execute(ITestMethod testMethod)
    {
        // ...
        return result;
    }
}

Sie müssen sie wie folgt ändern:

public sealed class MyTestMethodAttribute : TestMethodAttribute
{
    public override Task<TestResult[]> ExecuteAsync(ITestMethod testMethod)
    {
        // ...
        return Task.FromResult(result);
    }
}

TestMethodAttribute verwendet jetzt Attribute der Aufruferinformationen

Der TestMethodAttribute-Konstruktor wurde geändert, um Parameter aufzunehmen, die Informationen über die Aufruferattribute bereitstellen.

  • Wenn Sie von TestMethodAttribute erben, sollten Sie auch einen Konstruktor bereitstellen, der die Informationen an die Basisklasse weiterleitet.

    public class MyTestMethodAttribute : TestMethodAttribute
{
    public MyTestMethodAttribute([CallerFilePath] string callerFilePath = "", [CallerLineNumber] int callerLineNumber = -1)
    : base(callerFilePath, callerLineNumber)
    {
    }
}

  • Wenn Sie Attributanwendungen wie [TestMethodAttribute("Custom display name")] haben, wechseln Sie zu [TestMethodAttribute(DisplayName = "Custom display name")].

Tip

Ein Analyzer mit einem Codefix wird ihnen bei dieser Migration helfen. Ein einzelner Klick in der IDE korrigiert alle Instanzen in Ihrer Lösung.

ClassCleanupBehavior-Enumeration wird entfernt

Jetzt werden die ClassCleanup-Methoden nur am Ende der Testklasse ausgeführt. Die Unterstützung für die Klassenbereinigung, die am Ende der Assembly ausgeführt werden soll, wird entfernt. Wenn Sie eine Bereinigungslogik am Ende der Zusammenstellung ausführen müssen, tun Sie dies in AssemblyCleanup statt in ClassCleanup. Das Standardverhalten der Klassenbereinigung war zuvor "EndOfAssembly", die Benutzer als Fehler betrachteten.

Wenn Sie zuvor den folgenden Code hatten:

[ClassCleanup(ClassCleanupBehavior.EndOfClass)]
public static void ClassCleanup(TestContext testContext)
{
}

Sie müssen sie wie folgt ändern:

[ClassCleanup]
public static void ClassCleanup(TestContext testContext)
{
}

TestContext.Properties ist jetzt IDictionary<-Zeichenfolge, -Objekt>

Zuvor war TestContext.Properties ein IDictionary. Um eine bessere Eingabe zu ermöglichen, ist es jetzt IDictionary<string, object>.

Wenn Sie Aufrufe zu TestContext.Properties.Contains haben, aktualisieren Sie diese auf TestContext.Properties.ContainsKey.

Die TestTimeout-Enumeration wird entfernt

Diese Enumeration hatte nur ein einzelnes Element, Infinitedessen Wert lautete int.MaxValue. Wenn Sie [Timeout(TestTimeout.Infinite)] verwendet haben, aktualisieren Sie diese auf [Timeout(int.MaxValue)].

TestContext.ManagedType wird jetzt entfernt.

Die Eigenschaft TestContext.ManagedType wird entfernt. Verwenden Sie stattdessen TestContext.FullyQualifiedTestClassName.

Typen, die nicht für den öffentlichen Gebrauch bestimmt sind, werden entweder intern genutzt oder entfernt

  • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod wird intern festgelegt.
    • Beachten Sie, dass sich diese Schnittstelle von ITestMethod in der TestFramework-Assembly unterscheidet, die sich nicht geändert hat.
    • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod hat keine gültigen Verwendungen für Benutzer, daher wurde sie intern gemacht.
  • Einige der bereits veralteten Typen werden intern erstellt. Dies schließt Folgendes ein:
    • MSTestDiscoverer
    • MSTestExecutor
    • AssemblyResolver
    • LogMessageListener
    • TestExecutionManager
    • TestMethodInfo
    • TestResultExtensions
    • UnitTestOutcomeExtensions
    • GenericParameterHelper
    • Typen in der Plattformdienste-Assembly

Signaturänderung der Assert-APIs

  • Assert-APIs, die beide message und object[] Parameter akzeptieren, akzeptieren jetzt nur message. Verwenden Sie stattdessen die Zeichenfolgeninterpolation. Dies war eine notwendige Änderung zur Unterstützung des Aufruferargumentausdrucks für Assertions-APIs.
  • Assert.AreEqual APIs für IEquatable<T> werden entfernt. Es gibt nur wenige Benutzer dieser API, und die API ist irreführend. Die meisten Benutzer sind von dieser Entfernung nicht betroffen, da die API anfänglich in MSTest v3 nicht vorhanden war und in 3.2.2 eingeführt wurde.
    • Diese API verursacht auch Probleme für F#-Benutzer. Siehe z. B. fsharp/fslang-suggestions/issues/905.
    • Wenn Sie betroffen sind, erhalten Sie einen Kompilierungsfehler bezüglich der generischen Typableitung. Alles, was Sie tun müssen, ist, das Typargument explizit als object anzugeben.
  • Die veralteten Assert.ThrowsException APIs werden entfernt. Ein Analyzer und Codefix in MSTest 3.10 helfen Ihnen bei der Migration zu den neueren APIs.
  • Die Verwendung von Assert.IsInstanceOfType<T>(x, out var t) sollte jetzt zu var t = Assert.IsInstanceOfType<T>(x) geändert werden.
    • Vorhandene Überladungen, die den out Parameter nicht enthalten, wurden geändert, um die Instanz des Typs T anstelle von void zurückzugeben. Dies ist nur eine bahnbrechende Änderung für F#.

Die ExpectedExceptionAttribute-API wird entfernt.

Die veraltete ExpectedExceptionAttribute API wird entfernt. Ein Analyzer (MSTEST0006) und Codefix in MSTest 3.2 helfen Ihnen bei der Migration zu Assert.Throws.

Beispiel: Wenn Sie den folgenden Code hatten:

[ExpectedException(typeof(SomeExceptionType))]
[TestMethod]
public void TestMethod()
{
    MyCall();
}

Sie (oder der Analyzer und Codefix) müssen es folgendermaßen ändern:

[TestMethod]
public void TestMethod()
{
    Assert.ThrowsExactly<SomeExceptionType>(() => MyCall());
}

Die nicht unterstützten Zielframeworks wurden entfernt.

Die Unterstützung für Zielframeworks von .NET Core 3.1 bis einschließlich .NET 7 wird eingestellt. Die mindestens unterstützte .NET-Version ist .NET 8. Diese Änderung wirkt sich nicht auf .NET Framework aus. .NET Framework 4.6.2 ist weiterhin das mindest unterstützte .NET Framework-Ziel.

Die Entfaltungsstrategie wurde aus einzelnen Datenquellen in TestMethodAttribute verschoben

Die Entfaltungsstrategie ist eine in MSTest 3.7 eingeführte Funktion, um bekannte Einschränkungen zu umgehen. Die Eigenschaft wurde einzelnen Datenquellen wie DataRowAttribute und DynamicDataAttribute hinzugefügt. Diese Eigenschaft wurde nach TestMethodAttribute bewegt.

ConditionBaseAttribute.ShouldRun API-Änderung

Die ConditionBaseAttribute.ShouldRun Eigenschaft wurde umbenannt in IsConditionMet. Das macht deutlicher, dass ConditionMode in der Implementierung nicht verwendet werden sollte.

Mehrere Analysewerkzeuge werden standardmäßig so konfiguriert, dass sie Warnungen auslösen.

Der Standardschweregrad der folgenden Analysegeräte wurde von "Info" in "Warnung" geändert:

Breaking Changes für Verhalten

Dies sind weitreichende Änderungen, die sich auf das Verhalten zur Laufzeit auswirken können.

DisableAppDomain ist jetzt standardmäßig auf "true" festgelegt, wenn sie unter "Microsoft.Testing.Platform" ausgeführt wird.

In v4 und bei der Ausführung mit Microsoft.Testing.Platform sind AppDomains standardmäßig (wenn nicht angegeben) deaktiviert, da die bereitgestellte benutzerdefinierte Isolation in den meisten Fällen nutzlos ist und wichtige Auswirkungen auf die Leistung hat (bis zu 30% langsamer, wenn sie unter Isolation ausgeführt wird).

Das Feature ist jedoch weiterhin verfügbar. Wenn Sie Szenarien haben, die dies erfordern, fügen Sie die DisableAppDomain Einstellungen in Runsettings hinzu.

TestContext löst einen Fehler aus, wenn es falsch verwendet wird

Der TestContext Typ wird an "AssemblyInitialize", "ClassInitialize" und an Tests übergeben, verfügbare Informationen sind jedoch in jeder Phase unterschiedlich. Eine Ausnahme wird nun ausgelöst, wenn im Rahmen von AssemblyInitialize oder ClassInitialize auf eine Eigenschaft im Zusammenhang mit einer Testausführungsinformation zugegriffen wird.

  • Auf TestContext.FullyQualifiedTestClassName kann in der Assemblyinitialisierung nicht zugegriffen werden.
  • TestContext.TestName kann in der Assemblyinitialisierung oder Klasseninitialisierung nicht zugegriffen werden.

TestCase.Id ändert sich

Um lange bestehende Fehler zu beheben, die viele Benutzer gemeldet haben, hat sich die Generation von TestCase.Id geändert. Dies wirkt sich auf Azure DevOps-Features aus, z. B. das Nachverfolgen von Testfehlern im Laufe der Zeit.

TreatDiscoveryWarningsAsErrors ist jetzt standardmäßig auf "true" festgelegt.

v4 verwendet strengere Standardwerte. Daher ist der Standardwert von TreatDiscoveryWarningsAsErrors jetzt true. Dies sollte eine transparente Änderung für die meisten Benutzer sein und anderen Benutzern helfen, versteckte Fehler aufzudecken.

MSTest.Sdk fügt bei Verwendung der Microsoft.Testing.Plattform keine Microsoft.NET.Test.Sdk-Referenz mehr hinzu.

Standardmäßig verwendet MSTest.Sdk Microsoft.Testing.Platform. Wenn die UseVSTest MSBuild-Eigenschaft auf "true" festgelegt ist, wird stattdessen VSTest verwendet. In MSTest 3.x hat das SDK auch bei Verwendung von Microsoft.Testing.Platform einen Verweis auf Microsoft.NET.Test.Sdk hinzugefügt (der VSTest-Unterstützung bietet). Dieser Paketverweis ist nicht erforderlich, wenn er mit Microsoft.Testing.Platform ausgeführt wird und in MSTest v4 entfernt wurde.

Wenn Sie vsTest weiterhin unterstützt haben möchten (z. B. wenn Sie mit vstest.console ausführen möchten), müssen Sie ihrem Projekt manuell einen Paketverweis auf Microsoft.NET.Test.Sdk das NuGet-Paket hinzufügen.

  • Last updated on