Migrer de VSTest vers Microsoft.Testing.Platform

Dans cet article, vous allez apprendre à migrer de VSTest vers Microsoft.Testing.Platform.

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 de Microsoft.Testing.Platform.

Opt-in pour utiliser Microsoft.Testing.Platform

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

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

Microsoft.Testing.Platform 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

Microsoft.Testing.Platform 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

Microsoft.Testing.Platform 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 le Kit de développement logiciel (SDK) .NET 9 et versions antérieures, il n’existe aucune prise en charge native de Microsoft.Testing.Platform 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

À compter du Kit de développement logiciel (SDK) .NET 10, il existe une prise en charge native de Microsoft.Testing.Platform. 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 Microsoft.Testing.Platform est différent et aucun argument centralisé n’est utilisé par tous les collecteurs de données. Avec Microsoft.Testing.Platform, 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 Microsoft.Testing.Platform, 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 lors de l’exécution avec Microsoft.Testing.Platform.

xUnit.net ne prend pas en charge le même format de filtre lors de l’exécution avec Microsoft.Testing.Platform. 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 Microsoft.Testing.Platform. Dans Microsoft.Testing.Platform, 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 Microsoft.Testing.Platform, n’importe quel journaliste). Chaque journaliste Microsoft.Testing.Platform 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 Microsoft.Testing.Platform, 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 principal Microsoft.Testing.Platform et a été remplacé par un fichier de configuration plus moderne testconfig.json . Toutefois, MSTest et NUnit prennent toujours en charge les anciens RunSettings lors de l'exécution de Microsoft.Testing.Platform 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 l’Explorateur de tests Visual Studio Code, vous devrez peut-être activer la prise en charge de Microsoft.Testing.Platform.

Visual Studio

Visual Studio Test Explorer prend en charge Microsoft.Testing.Platform à 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 Microsoft.Testing.Platform.

Azure DevOps

Lorsque vous utilisez des tâches Azure DevOps, vous devrez peut-être mettre à jour votre pipeline pour utiliser Microsoft.Testing.Platform, 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 Microsoft.Testing.Platform native pour le Kit de développement logiciel (SDK) .NET 10 et versions ultérieures via global.json le fichier, vous devez définir la tâche arguments pour qu’elle pointe correctement vers le répertoire des résultats vers lequel elle est utilisée, 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 Microsoft.Testing.Platform

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, Microsoft.Testing.Platform é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 Microsoft.Testing.Platform.

• Avec Microsoft.Testing.Platform, cet encodage est toujours conservé.
• Avec VSTest qui ne s’exécute pas en mode d’isolation (comportement par défaut de vstest.console), cet encodage est conservé, comme Microsoft.Testing.Platform.
• 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.