Migrez de VSTest vers Microsoft. Testing.Platform (MTP)

Dans cet article, vous allez apprendre à migrer de VSTest vers MTP.

Cet article se concentre sur les étapes de migration et le mappage d’arguments.

Si vous avez toujours besoin de choisir une plateforme, commencez par une vue d’ensemble des plateformes de test.

Si vous avez besoin d’un comportement détaillé des dotnet test modes, consultez Test avec dotnet test.

Si vous avez besoin d’une liste unique d’options de ligne de commande de plateforme et d’extension, consultez les informations de référence sur les options CLI MTP.

Choisir d'utiliser le MTP

La première étape de la migration consiste à opter pour l’utilisation de MTP.

Pour tous les cadres de test, ajoutez <OutputType>Exe</OutputType> à tous les projets de test dans la solution. Après cela, suivez les instructions spécifiques au cadre.

MSTest

MTP est pris en charge par MSTest à partir de la version 3.2.0. Toutefois, nous vous recommandons de mettre à jour vers la dernière version msTest disponible.

Pour vous inscrire, ajoutez <EnableMSTestRunner>true</EnableMSTestRunner> sous un PropertyGroup dans le fichier Directory.Build.props.

NUnit

MTP est pris en charge par NUnit3TestAdapter à partir de la version 5.0.0.

Pour vous inscrire, ajoutez <EnableNUnitRunner>true</EnableNUnitRunner> sous un PropertyGroup dans le fichier Directory.Build.props.

xUnit.net

MTP est pris en charge à partir de xunit.v3.

Pour vous inscrire, ajoutez <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> sous un PropertyGroup dans le fichier Directory.Build.props.

dotnet test

S'inscrire à .NET 9 SDK et versions antérieures

Dans .NET 9 SDK et versions antérieures, il n’existe aucune prise en charge native pour MTP pour dotnet test. La prise en charge repose sur l’infrastructure VSTest. Pour l'utiliser, ajoutez <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> sous un PropertyGroup dans le fichier Directory.Build.props.

Opter pour le SDK .NET 10 et les versions ultérieures

À partir de .NET 10 SDK, il existe une prise en charge native de MTP. Pour l’utiliser, vous devez spécifier l’exécuteur de test comme Microsoft.Testing.Platform dans global.json:

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Mettre à jour dotnet test les appels

Les options de ligne de commande de dotnet test sont divisées en deux catégories : les arguments liés à la génération et les arguments liés aux tests.

Les arguments liés à la compilation ne sont pas pertinents pour la plateforme de test et, par conséquent, n’ont pas besoin d’être mis à jour pour la nouvelle plateforme. Les arguments liés à la construction sont listés ici :

• -a|--arch <ARCHITECTURE>
• --artifacts-path <ARTIFACTS_DIR>
• -c|--configuration <CONFIGURATION>
• -f|--framework <FRAMEWORK>
• -e|--environment <NAME="VALUE">
• --interactive
• --no-build
• --nologo
• --no-restore
• -o|--output <OUTPUT_DIRECTORY>
• --os <OS>
• -r|--runtime <RUNTIME_IDENTIFIER>
• -v|--verbosity <LEVEL>

Les arguments liés aux tests sont spécifiques à VSTest et doivent donc être transformés pour correspondre à la nouvelle plateforme. Le tableau suivant montre le mappage entre les arguments VSTest et la nouvelle plateforme :

--collect

--collect est un point d’extensibilité général dans VSTest pour n’importe quel collecteur de données. Le modèle d’extensibilité de MTP est différent et aucun argument centralisé n’est utilisé par tous les collecteurs de données. Avec MTP, chaque collecteur de données peut ajouter sa propre option de ligne de commande. Par exemple, l’exécution de Microsoft CodeCoverage via VSTest peut être similaire à ce qui suit :

dotnet test --collect "Code Coverage;Format=cobertura"

Avec MTP, cela devient :

dotnet test --coverage --coverage-output-format cobertura

--filter

--filter est un filtre basé sur VSTest.

MSTest et NUnit prennent en charge le même format de filtre, même en cas d’exécution avec MTP.

xUnit.net ne prend pas en charge le même format de filtre lors de l’exécution avec MTP. Vous devez migrer du filtre VSTest vers la nouvelle fonctionnalité de filtrage dans xunit.v3, qui est implémentée à l'aide des options de commandes en ligne suivantes.

xUnit.net options spécifiques :

• --filter-class
• --filter-not-class
• --filter-method
• --filter-not-method
• --filter-namespace
• --filter-not-namespace
• --filter-trait
• --filter-not-trait
• --filter-query

Pour plus d’informations, consultez la documentation Microsoft.Testing.Platform pour xUnit.net et le langage de filtre de requête pour xUnit.net.

--logger

Ce qui était généralement appelé « enregistreur d’événements » dans VSTest est appelé « reporter » dans MTP. Dans MTP, la journalisation est explicitement à des fins de diagnostic uniquement.

Similaire à --collect, --logger est un point d’extensibilité général dans VSTest pour n’importe quel enregistreur d’événements (ou, dans le contexte de MTP, n’importe quel journaliste). Chaque reporter MTP est libre d’ajouter sa propre option de ligne de commande et, par conséquent, il n’existe aucune option de ligne de commande centralisée comme VSTest.--logger

L’un des enregistreurs d’événements VSTest très couramment utilisés est l’enregistreur d’événements TRX. Cet enregistreur d’événements est généralement appelé comme suit :

dotnet test --logger trx

Avec MTP, la commande devient :

dotnet test --report-trx

--settings

VSTest --settings est utilisé pour spécifier un fichier RunSettings pour l'exécution de tests. RunSettings n’est pas pris en charge par le MTP principal et a été remplacé par un fichier de configuration plus moderne testconfig.json . Toutefois, MSTest et NUnit prennent toujours en charge l’ancien RunSettings pendant l’exécution de MTP et --settings est toujours pris en charge.

vstest.console.exe

Si vous utilisez vstest.console.exe directement, nous vous recommandons de le remplacer par la dotnet test commande.

Explorateur de tests

Lorsque vous utilisez Visual Studio ou Visual Studio Code Explorateur de tests, vous devrez peut-être activer la prise en charge de MTP.

Visual Studio

Visual Studio Explorateur de tests prend en charge MTP à partir de la version 17.14. Si vous utilisez une version antérieure, vous devrez peut-être mettre à jour votre Visual Studio vers la dernière version.

Visual Studio Code

Visual Studio Code avec C# DevKit prend en charge MTP.

Azure DevOps

Lorsque vous utilisez Azure DevOps tâches, vous devrez peut-être mettre à jour votre pipeline pour utiliser MTP, en fonction de la tâche que vous utilisez.

Tâche VSTest

Si vous utilisez la tâche VSTest dans Azure DevOps, vous pouvez la remplacer par la tâche .NET Core.

Tâche CLI .NET Core

• Si vous avez un arguments personnalisé passé à la tâche, suivez les mêmes instructions pour la migration de dotnet test.

• Si vous utilisez la tâche DotNetCoreCLI sans opter pour l'expérience MTP native pour .NET 10 SDK et versions ultérieures via le fichier global.json, vous devez définir la tâche arguments pour pointer correctement vers le répertoire des résultats utilisé pour pointer, ainsi que le rapport TRX demandé. Par exemple:

  - task: DotNetCoreCLI@2
    displayName: Run unit tests
    inputs:
      command: 'test'
      arguments: '-- --report-trx --results-directory $(Agent.TempDirectory)'
  

Différences comportementales entre VSTest et MTP

Exécution de tests zéro

Si un assembly de test a exécuté zéro test, VSTest tolère cela et se termine avec succès. Toutefois, MTP échoue avec le code de sortie 8. Il existe plusieurs façons de contourner ce problème :

• Passez --ignore-exit-code 8 pour l’exécution de vos tests.

• Si vous souhaitez ignorer ce code de sortie pour un projet de test spécifique, ajoutez ce qui suit dans le fichier projet :

  <PropertyGroup>
    <TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>
  </PropertyGroup>
  

• Utilisez la variable d’environnement TESTINGPLATFORM_EXITCODE_IGNORE .

Préservation de Console.InputEncoding

Si vous exécutez vos tests dans une console où la page de codes a été explicitement modifiée (par exemple, dans Azure DevOps, la page de codes est définie sur 65001 qui correspond à UTF8), le comportement peut être différent entre VSTest et MTP.

• Avec MTP, cet encodage est toujours conservé.
• Avec VSTest ne s’exécutant pas en mode d’isolation (comportement par défaut de vstest.console), cet encodage est conservé, similaire à MTP.
• Avec VSTest s’exécutant en mode isolation (comportement par défaut de ), dotnet testcet encodage n’est pas conservé dans l’hôte de test, qui est le processus qui exécute les tests.

Si vous avez un test qui démarre un autre processus enfant et redirige sa sortie standard, vous pouvez rencontrer des problèmes si tous les éléments suivants s’appliquent :

• La page de codes de la console est définie sur 65001 (UTF8). Cela peut être le cas sur CI, mais pas généralement localement. Pour obtenir un comportement local similaire à ci, exécutez chcp 65001 avant d’exécuter les tests.
• Le processus enfant est démarré avec l'encodage non UTF-8. Cela peut également se produire si votre propre test définit également CreateNoWindow = true.

Cela est particulièrement problématique lorsque le processus enfant ne s’attend pas à voir le BOM UTF8 (marque d'ordre des octets), qu’il peut obtenir dans un précédent cas avec le .NET Framework.

Comme cette différence de comportement est susceptible d’être problématique spécifiquement pour l’octet boM, une solution de contournement consiste à définir InputEncoding pendant l’initialisation de l’assembly sur UTF8 sans boM :

Console.InputEncoding = new UTF8Encoding(encoderShouldEmitUTF8Identifier: false);

Une autre solution de contournement consiste à ne pas utiliser CreateNoWindow = true pour les processus enfants qui redirigent l’entrée standard.