Partager via

Migrer de VSTest vers Microsoft.Testing.Platform

Dans cet article, vous allez apprendre à migrer de VSTest vers 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.

Note

Lorsque vous utilisez MSTest.Sdk, Microsoft.Testing.Platform est utilisé par défaut, sauf <UseVSTest>true</UseVSTest> indication contraire.

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 un 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.

Important

Lors de l’exécution du support Microsoft.Testing.Platform dans ce mode, vous devez ajouter -- pour séparer les dotnet test arguments des arguments de la nouvelle plateforme. Par exemple : dotnet test --no-build -- --list-tests.

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"
  }
}

Important

Dans ce mode, l’extra -- n’est plus utilisé.

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 :

Argument VSTest Nouvel argument de plateforme
--test-adapter-path <ADAPTER_PATH> Non pertinent pour Microsoft.Testing.Platform
--blame Non pertinent pour Microsoft.Testing.Platform
--blame-crash --crashdump (nécessite l'extension Crash dump)
--blame-crash-dump-type <DUMP_TYPE> --crashdump-type (nécessite l’extension de vidage sur incident)
--blame-crash-collect-always Non prise en charge
--blame-hang --hangdump (nécessite l’extension hang dump)
--blame-hang-dump-type <DUMP_TYPE> --hangdump-type (nécessite l’extension hang dump)
--blame-hang-timeout <TIMESPAN> --hangdump-timeout (nécessite l’extension hang dump)
--collect <DATA_COLLECTOR_NAME> Dépend du collecteur de données
-d\|--diag <LOG_FILE> --diagnostic
--filter <EXPRESSION> Dépend de l’infrastructure de test sélectionnée
-l\|--logger <LOGGER> Dépend de l’enregistreur
--results-directory <RESULTS_DIR> --results-directory <RESULTS_DIR>
-s\|--settings <SETTINGS_FILE> Dépend de l’infrastructure de test sélectionnée
-t\|--list-tests --list-tests
-- <RunSettings arguments> --test-parameter (fourni par VSTestBridge)

--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

Important

Comme expliqué précédemment, lors de l’utilisation de Microsoft.Testing.Platform avec la plateforme basée sur VSTest dotnet test, des arguments supplémentaires -- sont nécessaires avant les arguments qui doivent être passés à la plateforme. Donc, ça 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

Important

Pour l’utiliser --report-trx, vous devez installer le Microsoft.Testing.Extensions.TrxReport package NuGet.

Important

Comme expliqué précédemment, lors de l’utilisation de Microsoft.Testing.Platform avec la plateforme basée sur VSTest dotnet test, des -- supplémentaires sont nécessaires avant les arguments qui doivent être transmis à la plateforme. Donc, ça 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)
  • Last updated on