Udostępnij przez

Migrowanie z programu MSTest v3 do wersji 4

Stabilna wersja MSTest v4 jest teraz dostępna. Ten przewodnik migracji zawiera informacje o tym, co zmieniło się w programie MSTest w wersji 4 i jak można przeprowadzić migrację do tej wersji.

Note

Ogólnie rzecz biorąc, MSTest v4 nie jest zgodny binarnie z MSTest v3. Każda biblioteka skompilowana w wersji 3 musi być ponownie skompilowana względem wersji 4.

Zmiany wprowadzające niekompatybilność źródła

Są to zmiany powodujące niekompatybilność, które mogą spowodować problemy z kompilacją projektów testowych.

Zmiany powodujące niezgodność elementu TestMethodAttribute

Zmień element TestMethodAttribute.Execute na TestMethodAttribute.ExecuteAsync

Jeśli zaimplementujesz własne TestMethodAttribute, musisz zmienić przesłonięcie na Execute. Ta zmiana została wprowadzona w celu naprawienia długotrwałych błędów zakleszczenia, które są spowodowane blokującym charakterem synchronicznego działania interfejsu API.

Jeśli na przykład wcześniej wystąpiły następujące elementy:

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

Należy zmienić go na następujące:

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

TestMethodAttribute używa teraz atrybutów informacji o obiekcie wywołującym

Konstruktor TestMethodAttribute zmienił się tak, aby miał parametry, które zapewniają atrybuty informacji o wywołującym.

  • Jeśli dziedziczysz z TestMethodAttribute klasy, powinieneś także dostarczyć taki konstruktor, który propaguje informacje do klasy bazowej.

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

  • Jeśli masz aplikacje atrybutów, takie jak [TestMethodAttribute("Custom display name")], przełącz je na [TestMethodAttribute(DisplayName = "Custom display name")].

Tip

Analizator z poprawką kodu będzie wkrótce dostępny, aby pomóc w tej migracji. Jedno kliknięcie w IDE rozwiąże wszystkie wystąpienia w twoim rozwiązaniu.

Wyliczenie ClassCleanupBehavior zostało usunięte

Teraz metody ClassCleanup są uruchamiane tylko na końcu klasy testowej. Obsługa oczyszczania klasy, która miała być uruchomiona na końcu zgromadzenia, zostaje usunięta. Jeśli musisz uruchomić logikę czyszczenia po zakończeniu zestawiania, zrób to w AssemblyCleanup zamiast w ClassCleanup. Domyślne zachowanie oczyszczania klasy było wcześniej "EndOfAssembly", co użytkownicy uznali za błąd.

Jeśli wcześniej był następujący kod:

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

Należy zmienić go na następujące:

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

TestContext.Properties jest teraz typu IDictionary< string, object>

TestContext.Properties Wcześniej był elementem IDictionary. Aby zapewnić lepsze wpisywanie, jest to teraz IDictionary<string, object>.

Jeśli masz wywołania metody TestContext.Properties.Contains, zaktualizuj je do TestContext.Properties.ContainsKey.

Wyliczenie TestTimeout zostało usunięte

To wyliczenie miało tylko jeden element, Infinite, którego wartość to int.MaxValue. Jeśli używasz parametru [Timeout(TestTimeout.Infinite)], zaktualizuj je do [Timeout(int.MaxValue)].

Element TestContext.ManagedType jest teraz usuwany

Właściwość TestContext.ManagedType zostanie usunięta. Użyj TestContext.FullyQualifiedTestClassName zamiast tego.

Typy, które nie są przeznaczone do użytku publicznego, stają się wewnętrzne lub są usuwane

  • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod jest wykonany wewnętrznie.
    • Należy pamiętać, że ten interfejs różni się od interfejsu ITestMethod w zestawie TestFramework, który nie uległ zmianie.
    • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod nie ma żadnych prawidłowych użyć dla użytkowników, więc został wykonany wewnętrzny.
  • Niektóre z już przestarzałych typów zostały uczynione wewnętrznymi. Obejmuje to:
    • MSTestDiscoverer
    • MSTestExecutor
    • AssemblyResolver
    • LogMessageListener
    • TestExecutionManager
    • TestMethodInfo
    • Rozszerzenia TestResultExtensions
    • UnitTestOutcomeExtensions
    • GenericParameterHelper
    • Typy w zestawie usług platformy

Zmiana podpisu asercyjnych interfejsów API

  • API asercji, które akceptowały zarówno parametry message i object[], teraz akceptują tylko parametr message. Zamiast tego użyj interpolacji ciągów. Była to konieczna zmiana w celu obsługi wyrażeń argumentów wywołania dla API asercji.
  • Assert.AreEqual Interfejsy API dla programu IEquatable<T> są usuwane. Istnieje bardzo niewielu użytkowników tego interfejsu API, a interfejs API jest mylący. Większość użytkowników nie ma wpływu na to usunięcie, ponieważ interfejs API początkowo nie istniał w programie MSTest v3 i został wprowadzony w wersji 3.2.2.
    • Ten interfejs API powoduje również problemy z użytkownikami języka F#. Zobacz na przykład fsharp/fslang-suggestions/issues/905.
    • Jeśli cię to dotyczy, pojawi się błąd kompilacji związany z wnioskowaniem typów ogólnych. Wystarczy jawnie określić argument typu jako object.
  • Przestarzałe Assert.ThrowsException interfejsy API są usuwane. Analizator i poprawki kodu w narzędziu MSTest 3.10 ułatwiają migrację do nowszych interfejsów API.
  • Użycie polecenia Assert.IsInstanceOfType<T>(x, out var t) powinno teraz ulec zmianie na var t = Assert.IsInstanceOfType<T>(x).
    • Istniejące przeciążenia, które nie miały parametru out, zostały zmienione tak, aby zwracały wystąpienie typu T zamiast void. Jest to zmiana niekompatybilna tylko dla języka F#.

API ExpectedExceptionAttribute został usunięty

Przestarzały ExpectedExceptionAttribute interfejs API zostanie usunięty. Analizator (MSTEST0006) i poprawki kodu w programie MSTest 3.2 ułatwiają migrację do programu Assert.Throws.

Jeśli na przykład masz następujący kod:

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

Użytkownik (lub analizator i poprawki kodu) musi zmienić go na następujące:

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

Usunięte nieobsługiwane platformy docelowe

Obsługa platform docelowych .NET Core 3.1 do platformy .NET 7 została porzucona. Minimalna obsługiwana wersja platformy .NET to .NET 8. Ta zmiana nie ma wpływu na program .NET Framework. .NET Framework 4.6.2 nadal jest minimalną obsługiwaną platformą .NET Framework.

Strategia rozwijania przeniesiona z indywidualnych źródeł danych do atrybutu TestMethodAttribute

Strategia rozwijania to nowa funkcja wprowadzona w MSTest 3.7 do obejścia znanych ograniczeń. Właściwość została dodana do poszczególnych źródeł danych, takich jak DataRowAttribute i DynamicDataAttribute. Ta właściwość została przeniesiona do TestMethodAttribute.

ConditionBaseAttribute.ShouldRun Zmiana interfejsu API

Nazwa ConditionBaseAttribute.ShouldRun właściwości została zmieniona na IsConditionMet. To sprawia, że jest bardziej oczywiste, że ConditionMode nie powinno być używane w implementacji.

Wiele analizatorów jest domyślnie aktualizowanych w celu ostrzeżenia

Domyślny poziom ważności następujących analizatorów został zmieniony z Informacje na Ostrzeżenie.

Zmiany naruszające zgodność zachowania

Są to zmiany łamiące zgodność, które mogą mieć wpływ na zachowanie w czasie wykonywania.

Ustawienie DisableAppDomain teraz jest domyślnie ustawione na wartość true w przypadku działania w środowisku Microsoft.Testing.Platform

W wersji 4 oraz przy uruchamianiu z platformą Microsoft.Testing.Platform domyślnie wyłączone są domeny aplikacji (jeśli nie określono), ponieważ zapewniana niestandardowa izolacja jest bezużyteczna w większości przypadków i ma znaczący wpływ na wydajność (o 30% wolniejsza podczas pracy w izolacji).

Jednak funkcja pozostaje dostępna. Jeśli masz scenariusze wymagające ustawień, dodaj ustawienie DisableAppDomain w obszarze runsettings.

Ważne

Po włączeniu izolacji AppDomain, MSTest zwalnia AppDomain po zakończeniu wszystkich testów, co powoduje przerwanie wszystkich wątków skojarzonych z AppDomain, w tym wątków pierwszoplanowych. W związku z tym, jeśli wątek na pierwszym planie działałby w nieskończoność w MSTest v3, przebieg testu zakończy się pomyślnie. Ten sam scenariusz zawiesza się w środowisku MSTest w wersji 4, co jest idealnym zachowaniem, ponieważ proces nie powinien zakończyć się, gdy wątek pierwszego planu jest nadal uruchomiony.

Element TestContext zgłasza błąd, gdy jest używany nieprawidłowo

Typ TestContext jest przekazywany do metod AssemblyInitialize, ClassInitialize oraz do testów, ale dostępne informacje na każdym etapie są inne. Teraz zgłaszany jest wyjątek podczas uzyskiwania dostępu do właściwości powiązanej z informacjami o przebiegu testu w ramach elementu AssemblyInitialize lub ClassInitialize.

  • TestContext.FullyQualifiedTestClassName nie można uzyskać dostępu podczas inicjalizacji zestawu.
  • TestContext.TestName Nie można uzyskać dostępu w trakcie inicjalizacji zestawu lub inicjalizacji klasy.

TestCase.Id się zmienia

Aby rozwiązać długie zaległe usterki złożone przez wielu użytkowników, generacja TestCase.Id uległa zmianie. Ma to wpływ na funkcje usługi Azure DevOps, na przykład śledzenie niepowodzeń testów w czasie.

TreatDiscoveryWarningsAsErrors teraz domyślnie ma wartość true

Wersja 4 używa bardziej rygorystycznych ustawień domyślnych. W związku z tym wartość domyślna TreatDiscoveryWarningsAsErrors to teraz true. Powinna to być przezroczysta zmiana dla większości użytkowników i powinna pomóc innym użytkownikom w odkrywaniu ukrytych usterek.

MSTest.Sdk nie dodaje już odwołania Microsoft.NET.Test.Sdk podczas korzystania z pakietu Microsoft.Testing.Platform

Domyślnie biblioteka MSTest.Sdk używa biblioteki Microsoft.Testing.Platform. UseVSTest Jeśli właściwość MSBuild ma wartość true, zamiast tego użyje narzędzia VSTest. W narzędziu MSTest 3.x zestaw SDK dodał odwołanie do zestawu Microsoft.NET.Test.Sdk (który zapewnia obsługę programu VSTest), nawet w przypadku korzystania z biblioteki Microsoft.Testing.Platform. To odwołanie do pakietu jest niepotrzebne podczas używania z Microsoft.Testing.Platform i zostało usunięte w MSTest w wersji 4.

Jeśli nadal chcesz mieć obsługiwany VSTest (na przykład jeśli chcesz uruchomić vstest.console), musisz ręcznie dodać do projektu odwołanie do pakietu NuGet Microsoft.NET.Test.Sdk.

  • Last updated on