Partage via

Migrer de MSTest v3 vers v4

La version stable MSTest v4 est désormais disponible. Ce guide de migration explore les modifications apportées à MSTest v4 et la façon dont vous pouvez migrer vers cette version.

Note

En règle générale, MSTest v4 n’est pas compatible binaire avec MSTest v3. Toute bibliothèque compilée sur v3 doit être recompilée sur v4.

Changements non rétrocompatibles de la source

Ces modifications de rupture pourraient entraîner l’échec de la compilation de vos projets de test.

Modifications impliquant une rupture de compatibilité de TestMethodAttribute

Remplacer TestMethodAttribute.Execute par TestMethodAttribute.ExecuteAsync

Si vous implémentez votre propre TestMethodAttribute, vous devez modifier la surcharge Execute afin qu’elle devienne ExecuteAsync. Cette modification a été apportée pour corriger les bogues de blocage de longue date qui sont causés par la nature synchrone bloquante de l’API.

Par exemple, si vous aviez précédemment les éléments suivants :

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

Vous devez le remplacer par ce qui suit :

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

TestMethodAttribute utilise désormais des attributs d’informations de l’appelant

Le TestMethodAttribute constructeur a changé pour avoir des paramètres qui fournissent des attributs d'informations d'appelant.

  • Si vous héritez de TestMethodAttribute, vous devez également fournir un tel constructeur qui propage les informations à la classe de base.

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

  • Si vous avez des applications d’attribut telles que [TestMethodAttribute("Custom display name")], basculez-les vers [TestMethodAttribute(DisplayName = "Custom display name")].

Tip

Un analyseur avec un codefix est disponible pour vous aider à effectuer cette migration. Un seul clic dans l’IDE corrige toutes les instances de votre solution.

L’énumération ClassCleanupBehavior est supprimée

À présent, les méthodes ClassCleanup s’exécutent uniquement à la fin de la classe de test. La prise en charge du nettoyage de classe à exécuter à la fin de l’assembly est supprimée. Si vous devez exécuter la logique de nettoyage après l'assemblage, faites-le plutôt dans AssemblyCleanup que dans ClassCleanup. Le comportement par défaut du nettoyage de classe était auparavant « EndOfAssembly », ce que les utilisateurs considéraient comme un bogue.

Si vous aviez précédemment le code suivant :

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

Vous devez le remplacer par ce qui suit :

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

TestContext.Properties est maintenant IDictionary<string, object>

Auparavant, TestContext.Properties c’était un IDictionary. Pour fournir une meilleure saisie, il s’agit maintenant de IDictionary<string, object>.

Si vous avez des appels à TestContext.Properties.Contains, mettez-les à jour vers TestContext.Properties.ContainsKey.

L’énumération TestTimeout est supprimée

Cette énumération n’avait qu’un seul membre, Infinitedont la valeur était int.MaxValue. Si vous aviez des utilisations de [Timeout(TestTimeout.Infinite)], mettez-les à jour vers [Timeout(int.MaxValue)].

TestContext.ManagedType est maintenant supprimé

La propriété TestContext.ManagedType est supprimée. Utilisez TestContext.FullyQualifiedTestClassName à la place.

Les types non destinés à un usage public sont rendus internes ou supprimés

  • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod est rendu interne.
    • Notez que cette interface est différente de ITestMethod dans l’assembly TestFramework, qui n’a pas changé.
    • Microsoft.VisualStudio.TestPlatform.MSTestAdapter.PlatformServices.Interface.ObjectModel.ITestMethod n’a pas d’utilisation valide pour les utilisateurs, il a donc été rendu interne.
  • Certains des types déjà obsolètes sont rendus internes. notamment :
    • MSTestDiscoverer
    • MSTestExecutor
    • AssemblyResolver
    • ÉcouteurDeMessagesDeJournal
    • TestExecutionManager
    • TestMethodInfo
    • TestResultExtensions
    • UnitTestOutcomeExtensions
    • GenericParameterHelper
    • Types dans l’assemblage des services de plateforme

Changement de signature des API Assert

  • Les API qui acceptent à la fois les paramètres message et object[] acceptent désormais uniquement message. Utilisez plutôt l’interpolation de chaîne. Il s’agissait d’une modification nécessaire pour prendre en charge l’expression d’argument de l’appelant pour les API d’assertion.
  • Assert.AreEqual Les API pour IEquatable<T> sont supprimées. Il existe très peu d’utilisateurs de cette API et l’API est trompeuse. La plupart des utilisateurs ne sont pas affectés par cette suppression, car l’API n’existe pas initialement dans MSTest v3 et a été introduite dans la version 3.2.2.
    • Cette API provoque également des problèmes pour les utilisateurs F#. Par exemple, consultez fsharp/fslang-suggestions/issues/905.
    • Si vous êtes concerné, vous obtenez une erreur de compilation sur l’inférence de type générique. Tout ce que vous devez faire est de spécifier explicitement l’argument de type en tant que object.
  • Les API déconseillées Assert.ThrowsException sont supprimées. Un analyseur et un codefix dans MSTest 3.10 vous aident à migrer vers les API plus récentes.
  • Les utilisations de Assert.IsInstanceOfType<T>(x, out var t) devraient maintenant passer à var t = Assert.IsInstanceOfType<T>(x).
    • Les surcharges existantes qui n’avaient pas le paramètre out ont été modifiées pour renvoyer l’instance de type T au lieu de void. Il s’agit uniquement d’un changement non rétrocompatible pour F#.

L’API ExpectedExceptionAttribute est supprimée

L’API déconseillée ExpectedExceptionAttribute est supprimée. Un analyseur (MSTEST0006) et un codefix dans MSTest 3.2 vous aident à migrer vers Assert.Throws.

Par exemple, si vous avez le code suivant :

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

Vous (ou l’analyseur et le codefix) devez le modifier comme suit :

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

Frameworks cibles non pris en charge supprimés

La prise en charge des frameworks cibles de .NET Core 3.1 à .NET 7 est arrêtée. La version minimale prise en charge de .NET est .NET 8. Cette modification n’affecte pas .NET Framework. .NET Framework 4.6.2 continue d’être la cible .NET Framework minimale prise en charge.

Stratégie de dépliement déplacée des sources de données individuelles vers TestMethodAttribute

La stratégie de déploiement est une fonctionnalité récente introduite dans MSTest 3.7 pour contourner les limitations connues. La propriété a été ajoutée sur des sources de données individuelles comme DataRowAttribute et DynamicDataAttribute. Cette propriété a été déplacée vers TestMethodAttribute.

ConditionBaseAttribute.ShouldRun Modification de l’API

La propriété ConditionBaseAttribute.ShouldRun a été renommée en IsConditionMet. Il est ainsi plus clair que ConditionMode ne doit pas être utilisé dans l’implémentation.

Plusieurs analyseurs sont mis à jour pour être avertis par défaut

La gravité par défaut des analyseurs suivants est passée d’Informations à Avertissement :

Modifications importantes du comportement

Ces changements de rupture peuvent affecter le comportement pendant l'exécution.

DisableAppDomain a désormais la valeur true lors de l’exécution sous Microsoft.Testing.Platform

Dans la version 4 et lors de l’exécution avec Microsoft.Testing.Platform, les domaines d’application sont désactivés par défaut (lorsqu’ils ne sont pas spécifiés), car l’isolation personnalisée fournie est inutile dans la plupart des cas et a un impact important sur les performances (jusqu’à 30% plus lent lors de l’exécution sous isolation).

Toutefois, la fonctionnalité reste disponible. Si vous avez des scénarios nécessitant cela, ajoutez le DisableAppDomain paramètre dans runsettings.

Important

Lorsque l’isolation AppDomain est activée, MSTest décharge l’AppDomain une fois tous les tests terminés, ce qui abandonne tous les threads associés à AppDomain, y compris les threads de premier plan. Par conséquent, si vous aviez un thread de premier plan s’exécutant indéfiniment dans MSTest v3, l’exécution du test s’exécute correctement. Le même scénario se bloque dans MSTest v4, ce qui est un comportement idéal, car le processus ne doit pas se quitter lorsqu’un thread de premier plan est toujours en cours d’exécution.

TestContext lève une exception lorsqu’il est utilisé de manière incorrecte

Le type TestContext est passé à AssemblyInitialize, ClassInitialize et aux tests, mais les informations disponibles diffèrent à chaque étape. À présent, une exception est générée lors de l’accès à une propriété liée à des informations d’exécution de test dans le cadre de AssemblyInitialize ou de ClassInitialize.

  • TestContext.FullyQualifiedTestClassName n'est pas accessible dans l'initialisation de l'assembly.
  • TestContext.TestName n’est pas accessible lors de l’initialisation de l’assembly ou de la classe.

TestCase.Id est en train de changer

Pour résoudre les bogues en attente depuis longtemps et déposés par de nombreux utilisateurs, la génération de TestCase.Id a changé. Cela affecte les fonctionnalités Azure DevOps, par exemple, le suivi des échecs de test au fil du temps.

TreatDiscoveryWarningsAsErrors est maintenant défini sur vrai par défaut

v4 utilise des valeurs par défaut plus strictes. Par conséquent, la valeur par défaut est TreatDiscoveryWarningsAsErrors maintenant true. Il doit s’agir d’un changement transparent pour la plupart des utilisateurs et aider d’autres utilisateurs à découvrir les bogues cachés.

MSTest.Sdk n’ajoute Microsoft.NET.Test.Sdk plus de référence lors de l’utilisation de Microsoft.Testing.Platform

Par défaut, MSTest.Sdk utilise Microsoft.Testing.Platform. Si la propriété MSBuild est définie sur true, VSTest sera utilisé à la place. Dans MSTest 3.x, le SDK a ajouté une référence à Microsoft.NET.Test.Sdk (qui apporte la prise en charge de VSTest), même lors de l’utilisation de Microsoft.Testing.Platform. Cette référence de package n’est pas nécessaire lors de l’exécution avec Microsoft.Testing.Platform et a été supprimée dans MSTest v4.

Si vous souhaitez toujours que VSTest soit pris en charge (par exemple, si vous souhaitez exécuter avec vstest.console), vous devez ajouter manuellement une référence de package au Microsoft.NET.Test.Sdk package NuGet à votre projet.

  • Last updated on