Partager via

test dotnet avec Microsoft.Testing.Platform (MTP)

Cet article s’applique à : ✔️ SDK .NET 10 et versions ultérieures

Nom

dotnet test - Pilote de test .NET utilisé pour exécuter des tests unitaires avec Microsoft.Testing.Platform.

Synopsis

dotnet test
    [--project <PROJECT_PATH>]
    [--solution <SOLUTION_PATH>]
    [--test-modules <EXPRESSION>] 
    [--root-directory <ROOT_PATH>]
    [--max-parallel-test-modules <NUMBER>]
    [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>]
    [--os <OS>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [-v|--verbosity <LEVEL>]
    [--no-build]
    [--no-restore]
    [--no-ansi]
    [--no-progress]
    [--output <VERBOSITY_LEVEL>]
    [--no-launch-profile]
    [--no-launch-profile-arguments]
    [<args>...]

dotnet test -h|--help

Descriptif

Avec la plateforme de test Microsoft, dotnet test fonctionne plus rapidement qu’avec VSTest. Les arguments liés aux tests ne sont plus résolus, car ils sont liés aux extensions inscrites dans le ou les projets de test. De plus, MTP prend en charge un filtre globbing lors de l’exécution de tests. Pour plus d’informations, consultez Microsoft.Testing.Platform.

Avertissement

Lorsque Microsoft.Testing.Platform est choisi via global.json, dotnet test s’attend à ce que tous les projets de test utilisent Microsoft.Testing.Platform. Il s’agit d’une erreur si l’un des projets de test utilise VSTest.

Restauration implicite

Vous n’avez pas besoin d’exécuter dotnet restore, car il est exécuté implicitement par toutes les commandes qui nécessitent une restauration pour se produire, comme dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish et dotnet pack. Pour désactiver la restauration implicite, utilisez l’option --no-restore .

La commande dotnet restore est toujours utile dans certains scénarios où la restauration explicite est logique, comme les builds d’intégration continue dans Azure DevOps Services ou dans les systèmes de génération qui doivent contrôler explicitement le moment où la restauration se produit.

Pour plus d’informations sur la gestion des flux NuGet, consultez la documentation dotnet restore.

Options

Note

Vous ne pouvez utiliser qu’une des options suivantes à la fois : --project, --solutionou --test-modules. Ces options ne peuvent pas être combinées. En outre, lorsque vous utilisez --test-modules, vous ne pouvez pas spécifier --arch, --configuration, --framework, --osou --runtime. Ces options ne sont pas pertinentes pour un module déjà intégré.

  • --project <PROJECT_PATH>

    Spécifie le chemin du fichier projet à exécuter (nom de dossier ou chemin complet). Si aucune valeur n’est spécifiée, le répertoire actif est utilisé par défaut.

  • --solution <SOLUTION_PATH>

    Spécifie le chemin d’accès du fichier solution à exécuter (nom du dossier ou chemin d’accès complet). Si aucune valeur n’est spécifiée, le répertoire actif est utilisé par défaut.

  • --test-modules <EXPRESSION>

    Filtre les modules de test à l’aide du globbing de fichiers dans .NET. Seuls les tests appartenant à ces modules de test s’exécuteront. Pour plus d’informations et d’exemples sur l’utilisation du globbing de fichiers dans .NET, consultez de globbing de fichiers.

  • --root-directory <ROOT_PATH>

    Spécifie le répertoire racine de l’option --test-modules. Elle ne peut être utilisée qu’avec l’option --test-modules.

  • --max-parallel-test-modules <NUMBER>

    Spécifie le nombre maximal de modules de test pouvant s’exécuter en parallèle. La valeur par défaut est Environment.ProcessorCount.

  • -a|--arch <ARCHITECTURE>

    Spécifie l’architecture cible. Il s’agit d’une syntaxe abrégée pour définir l’identificateur d’exécution (RID), où la valeur fournie est combinée avec le RID par défaut. Par exemple, sur une machine win-x64, la spécification de --arch x86 définit le RID sur win-x86. Si vous utilisez cette option, n’utilisez pas l’option -r|--runtime. Disponible depuis .NET 6 Preview 7.

  • -c|--configuration <CONFIGURATION>

    Définit la configuration de build. La valeur par défaut pour la plupart des projets est Debug, mais vous pouvez remplacer les paramètres de configuration de build dans votre projet.

  • -f|--framework <FRAMEWORK>

    Moniker de framework cible (TFM) du framework cible pour lequel les tests doivent être exécutés. Le framework cible doit être spécifié dans le fichier projet.

  • --os <OS>

    Spécifie le système d’exploitation cible. Il s’agit d’une syntaxe abrégée pour définir l’identificateur d’exécution (RID), où la valeur fournie est combinée avec le RID par défaut. Par exemple, sur une machine win-x64, la spécification de --os linux définit le RID sur linux-x64. Si vous utilisez cette option, n’utilisez pas l’option -r|--runtime. Disponible depuis .NET 6.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Runtime cible à tester.

    -r abrégé disponible à partir du kit SDK .NET 7.

    Note

    L’exécution de tests pour une solution avec une propriété globale RuntimeIdentifier (explicitement ou via --arch, --runtimeou --os) n’est pas prise en charge. Définissez RuntimeIdentifier plutôt un niveau de projet individuel.

  • -v|--verbosity <LEVEL>

    Définit le niveau de détail de la commande. Les valeurs autorisées sont q[uiet], m[inimal], n[ormal], d[etailed] et diag[nostic]. Pour plus d’informations, consultez LoggerVerbosity.

  • --no-build

    Spécifie que le projet de test n’est pas généré avant d’être exécuté. Il définit également implicitement l’indicateur de --no-restore.

  • --no-restore

    Spécifie qu’une restauration implicite n’est pas exécutée lors de l’exécution de la commande.

  • --no-ansi

    Désactive la sortie des caractères d’échappement ANSI à l’écran.

  • --no-progress

    Désactive la progression de la création de rapports à l’écran.

  • --output <VERBOSITY_LEVEL>

    Spécifie le détail de sortie lors de la création de rapports de tests. Les valeurs valides sont Normal et Detailed. La valeur par défaut est Normal.

  • --no-launch-profile

    N’essayez pas d’utiliser launchSettings.json pour configurer l’application. Par défaut, launchSettings.json il est utilisé, qui peut appliquer des variables d’environnement et des arguments de ligne de commande au fichier exécutable de test.

  • --no-launch-profile-arguments

    N’utilisez pas d’arguments spécifiés par commandLineArgs le profil de lancement pour exécuter l’application.

  • --property:<NAME>=<VALUE>

    Définit une ou plusieurs propriétés de MSBuild. Spécifiez plusieurs propriétés en répétant l’option :

    --property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

    La forme abrégée -p peut être utilisée pour --property. La même chose s’applique à /property:property=value et sa forme courte est /p. Vous trouverez plus d’informations sur les arguments disponibles dans la documentation dotnet msbuild.

  • -?|-h|--help

    Imprime une description de l’utilisation de la commande.

  • args

    Spécifie des arguments supplémentaires à passer à la ou les applications de test. Utilisez un espace pour séparer plusieurs arguments. Pour plus d’informations et d’exemples sur la transmission, consultez vue d’ensemble de Microsoft.Testing.Platform et extensions Microsoft.Testing.Platform.

    Conseil / Astuce

    Pour spécifier des arguments supplémentaires pour des projets spécifiques, utilisez la propriété TestingPlatformCommandLineArguments MSBuild.

Note

Pour activer la journalisation des traces dans un fichier, utilisez la variable d’environnement DOTNET_CLI_TEST_TRACEFILE pour fournir le chemin d’accès au fichier de trace.

Examples

  • Exécutez les tests dans le projet ou la solution dans le répertoire actif :

    dotnet test

  • Exécuter les tests dans le projet TestProject :

    dotnet test --project ./TestProject/TestProject.csproj

  • Exécutez les tests dans la solution TestProjects :

    dotnet test --solution ./TestProjects/TestProjects.sln

  • Exécutez les tests à l’aide de l’assembly TestProject.dll :

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll"

  • Exécutez les tests à l’aide de TestProject.dll assembly avec le répertoire racine :

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll" --root-directory "c:\code"

  • Exécutez les tests dans le répertoire actif avec la couverture du code :

    dotnet test --coverage

  • Exécutez les tests du projet TestProject, en fournissant l’argument -bl (journal binaire) à msbuild :

    dotnet test --project ./TestProject/TestProject.csproj -bl

  • Exécutez les tests du projet TestProject, en définissant la propriété MSBuild DefineConstants sur DEV :

    dotnet test --project ./TestProject/TestProject.csproj -p:DefineConstants="DEV"

Voir aussi

  • Last updated on