test dotnet avec Microsoft.Testing.Platform (MTP)

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

Nom

dotnet test - .NET pilote de test utilisé pour exécuter des tests unitaires avec MTP.

Synopsis

dotnet test
    [<PROJECT_OR_TRAVERSAL_PATH>]
    [--project <PROJECT_PATH>]
    [--solution <SOLUTION_PATH>]
    [--test-modules <EXPRESSION>]
    [--root-directory <ROOT_PATH>]
    [--max-parallel-test-modules <NUMBER>]
    [--config-file <CONFIG_FILE>]
    [--results-directory <RESULTS_DIRECTORY>]
    [--results-directory-layout <flat|per-module>]
    [--diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>]
    [--minimum-expected-tests <NUMBER>]
    [--maximum-failed-tests <NUMBER>]
    [--timeout <DURATION>]
    [-e|--environment <NAME="VALUE">]
    [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>]
    [--os <OS>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--use-current-runtime|--ucr]
    [-v|--verbosity <LEVEL>]
    [--no-build]
    [--no-dependencies]
    [--no-restore]
    [--nologo|--no-logo|--no-banner]
    [--no-ansi]
    [--no-progress]
    [--no-artifact-post-processing]
    [--output <VERBOSITY_LEVEL>]
    [--show-test-results <OUTCOME>]
    [--list-tests [text|json]]
    [--no-launch-profile]
    [--no-launch-profile-arguments]
    [--device <DEVICE_ID>]
    [--list-devices]
    [--collect-test-map]
    [--affected-tests]
    [<args>...]

dotnet test -h|--help

Descriptif

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

Important

Les options spécifiques à l’extension ne sont pas intégrées à MTP. Chaque application de test ciblée doit inscrire l’extension qui fournit une option. Ajoutez directement le package NuGet de l’extension, ou utilisez une configuration ou un profil sdk de test qui inclut le package. Sinon, l’exécution du test échoue avec le code de sortie 5, car l’option n’est pas reconnue. Exécutez dotnet test --help pour afficher les options disponibles pour les applications de test sélectionnées et voir les options d’extension par scénario pour rechercher le package pour une option.

Avertissement

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

Exigences de version

Le mode MTP requiert dotnet test le kit SDK .NET 10 et MTP 1.7 ou version ultérieure. Les options ajoutées après .NET 10 ont des exigences de version individuelles du Kit de développement logiciel (SDK) dans les sections suivantes. Certaines options nécessitent également un package MTP plus récent, car le SDK coordonne l’exécution complète pendant que chaque application de test implémente la fonctionnalité correspondante.

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 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, --solution ou --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--device, --framework, , --list-devices, , --os, , --runtime, ou --use-current-runtime. Ces options nécessitent une évaluation de projet ou ne sont pas pertinentes pour un module déjà intégré.

  • PROJECT_OR_TRAVERSAL_PATH

    Spécifie un projet ou un projet de traversée à exécuter. À compter de .NET 11 Preview 7, dotnet test prend en charge Microsoft.Build.Traversal les projets, tels que dirs.proj, et exécute de manière récursive leurs projets de test référencés.

    À partir de .NET 12 Preview 1, l’argument peut également identifier une application de test MTP basée sur un fichier C#. Les applications de test basées sur des fichiers ne prennent pas en charge --device.

  • --project <PROJECT_PATH>

    Spécifie le chemin d’accès du fichier project à 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.

  • --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. Seuls les tests appartenant à ces modules de test s’exécutent. À compter de .NET 11 Preview 6, préfixez un modèle avec ! pour exclure les modules correspondants. Séparez plusieurs modèles avec des points-virgules ; les espaces blancs autour de chaque modèle sont ignorés.

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

  • --config-file <CONFIG_FILE>

    Spécifie le fichier de configuration à utiliser pour l’exécution de test. Si un chemin relatif est fourni, il est converti en chemin absolu en fonction du répertoire actif. Pour plus d’informations sur les paramètres du fichier de configuration, consultez testconfig.json.

  • --results-directory <RESULTS_DIRECTORY>

    Spécifie le répertoire dans lequel les résultats des tests sont stockés. Si le répertoire n’existe pas, il est créé. Si un chemin relatif est fourni, il est converti en chemin absolu en fonction du répertoire actif.

  • --results-directory-layout <flat|per-module>

    Spécifie comment une exécution multimodèle organise les fichiers sous le répertoire des résultats. La valeur par défaut, flatécrit tous les résultats dans le même répertoire. per-module écrit les résultats de chaque module dans <project>/<target-framework>_<runtime-or-architecture>, ce qui empêche les rapports portant le même nom de fichier de se remplacer les uns les autres.

    Disponible à partir de .NET 11 RC 1.

  • --diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>

    Spécifie le répertoire dans lequel la sortie de diagnostic est stockée. Si le répertoire n’existe pas, il est créé. Si un chemin relatif est fourni, il est converti en chemin absolu en fonction du répertoire actif.

  • --minimum-expected-tests <NUMBER>

    Spécifie un nombre minimal positif de tests pour l’ensemble de l’exécution. Si le nombre de tests agrégés est inférieur au minimum spécifié, l’exécution du test échoue avec le code de sortie 9. Le nombre global comprend des tests ignorés. Pour plus d’informations sur les codes de sortie, consultez les codes de sortie MTP.

    Étant donné que cette option apparaît avant --, il s’agit d’une option globale (exécution entière). Pour exiger un minimum pour chaque module de test, passez l’option après -- afin qu’elle soit transférée à chaque module de test. Pour plus d’informations, consultez Minimums d’exécution et par module.

    Note

    Le minimum global nécessite le sdk .NET 10 (10.0.100) ou une version ultérieure.

  • --maximum-failed-tests <NUMBER>

    Arrête l’exécution complète une fois qu’elle atteint le nombre spécifié d’échecs, d’erreurs, de délais d’attente ou d’annulation de tests. L’exécution s’arrête avec le code 13.

    Disponible à partir de .NET 11 Preview 7 et nécessite MTP 2.4 ou version ultérieure.

  • --timeout <DURATION>

    Arrête l’exécution complète après la durée spécifiée pendant qu’au moins une application de test est en cours d’exécution. Spécifiez un nombre positif suivi d’une unité, telle que 500ms, , 90s10m, 2h, ou 1d. Une exécution de délai d’attente s’arrête avec le code 3.

    Disponible à partir de .NET 11 Preview 7 et nécessite MTP 2.4 ou version ultérieure.

  • -e|--environment <NAME="VALUE">

    Définit une variable d’environnement pour le processus de test. Spécifiez l’option plusieurs fois pour définir plusieurs variables. Les valeurs de ligne de commande remplacent les valeurs d’un profil de lancement.

    Utilisez .NET SDK 10.0.110 ou version ultérieure lorsqu’aucun profil de lancement n’existe ou lorsque vous spécifiez --no-launch-profile; les versions antérieures .NET 10 SDK peuvent ignorer les variables dans ces cas. À compter de .NET 11 Preview 7, les variables circulent également vers des cibles de build, de déploiement et d’argument d’exécution prenant en charge les fonctionnalités.

  • -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 préversion 7.

  • --artifacts-path <ARTIFACTS_DIR>

    Tous les fichiers de sortie de build de la commande exécutée vont dans les sous-dossiers sous le chemin spécifié, séparés par projet. Pour plus d’informations, consultez disposition de sortie d’artefacts. Cette option et la valeur fournie doivent être explicitement en cascade dans n’importe quelle dotnet commande qui dépend de la sortie d’une autre dotnet commande, par exemple, lors de l’utilisation dotnet build --no-restore et dotnet publish --no-build. Disponible depuis .NET 8 SDK.

    Disponible pour le mode MTP à partir de .NET 11.

  • -c|--configuration <CONFIGURATION>

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

  • -f|--framework <FRAMEWORK>

    Moniker de framework cible (TFM) du framework cible pour lequel les tests doivent être exécutés. L’infrastructure cible doit également être spécifiée dans le fichier project.

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

    Formulaire court -r disponible à partir de .NET SDK 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 au niveau d’un project individuel à la place.

  • --use-current-runtime|--ucr

    Utilise le runtime actuel comme runtime cible pendant la restauration et la génération.

    Disponible à partir de .NET 11 Preview 6. Vous ne pouvez pas combiner cette option avec --test-modules.

  • -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 project de test n'est pas généré avant d'être exécuté. Il définit également implicitement l’indicateur de --no-restore.

  • --no-dependencies

    Ignore la création de références de projet à projet.

    Disponible à partir de .NET 11 Preview 6.

  • --no-restore

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

  • --nologo|--no-logo|--no-banner

    Supprime les bannières de démarrage .NET et MTP. Les -nologo formulaires et /nologo la variable d’environnement DOTNET_NOLOGO sont également pris en charge.

    Disponible en mode MTP à partir de .NET 11 Preview 7.

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

  • --no-artifact-post-processing

    Désactive le post-traitement des artefacts compatibles après l’exécution d’un multimodèle. À compter de .NET 11 RC 1 et MTP 2.4, les post-processeurs d’artefacts inscrits peuvent combiner des rapports compatibles, tels que les résultats TRX. En cas d’échec du post-traitement, le Kit de développement logiciel (SDK) conserve les artefacts d’origine et le code de sortie du test.

  • --output <VERBOSITY_LEVEL>

    Spécifie le détail de sortie pour les résultats des tests. Les valeurs valides sont Minimal, Normalet Detailed. La valeur par défaut est Normal. Minimal nécessite la préversion de MTP 2.4.

  • --show-test-results <OUTCOME>

    Sélectionne les blocs de résultats par résultat. Dans la préversion MTP 2.4, utilisez passed, , skippedfailed, , allou none. La failed valeur inclut également les erreurs, les délais d’expiration et les annulations.

    Combinez passed, failedet skipped avec des virgules, des espaces ou des options répétées --show-test-results . Ne combinez all pas ou none n’utilisez pas une autre valeur. Cette option explicite remplace la présélection, quelle que soit l’ordre --output des options.

  • --list-tests [text|json]

    Répertorie les tests découverts sans les exécuter. Omettez la valeur ou spécifiez text la sortie lisible par l’homme. À compter de .NET 11 Preview 7, spécifiez json un document JSON versionné qui regroupe les tests par assembly, framework cible et architecture et inclut des identificateurs disponibles, des emplacements sources, des méthodes, des paramètres et des caractéristiques.

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

  • --device <DEVICE_ID>

    Sélectionne un appareil, un émulateur ou un simulateur pour chaque infrastructure cible dans un projet de test Android ou iOS. Le chemin MTP prend également en charge les projets de test macOS et Mac Catalyst. Si l’entrée est interactive et que plusieurs appareils sont disponibles, dotnet test vous pouvez vous inviter à en sélectionner un.

    Disponible à partir de .NET 11 Preview 6. Pour les projets multi-ciblés, utilisez .NET 11 RC 2 ou version ultérieure afin que la découverte d’appareils évalue correctement chaque infrastructure cible. Les projets de test WebAssembly du navigateur ne sont pas pris en charge par cette option.

  • --list-devices

    Répertorie les appareils disponibles pour un projet sans exécuter de tests. Spécifiez un projet plutôt qu’une solution.

    Disponible à partir de .NET 11 Preview 7.

  • --collect-test-map et --affected-tests

    Collectez une carte de test de référentiel ou exécutez des tests affectés par une modification. Ces options expérimentales nécessitent une extension distribuée séparément et la variable d’environnement DOTNET_CLI_ENABLE_AFFECTED_TESTS=1 . Vous ne pouvez pas combiner les deux options. Les flux de travail de test affectés ne prennent pas en charge les tests d’appareil, les modules de test parallèles ou les stratégies de test minimum.

    Disponible à partir de .NET 11 RC 1.

  • --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 la vue d’ensemble de MTP et les fonctionnalités MTP.

    Conseil / Astuce

    Pour spécifier des arguments supplémentaires pour des projets spécifiques, utilisez la propriété TestingPlatformCommandLineArguments MSBuild. Cette propriété est particulièrement utile lorsque votre solution combine des frameworks de test (par exemple, MSTest et xUnit.net) ou lorsque seuls certains projets référencent une extension particulière. Pour plus d’informations, consultez Solutions avec des frameworks de test ou des extensions mixtes.

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.

À compter de .NET 11 RC 1, dotnet test -bl utilise une session MSBuild pour les exécutions multi-projets, multi-ciblés et d’appareils afin que le journal binaire contienne la build complète.

Comportement de sortie et d’annulation

À compter de .NET 11 Preview 6, la sortie ANSI interactive affiche les tests en cours d’exécution et les rapports par nombre de tests d’assembly. L’affichage de progression reste désactivé lorsque la sortie est redirigée, ANSI ou la sortie de progression est désactivée ou que l’environnement n’est pas interactif.

À compter de .NET 11 Preview 6, la première touche Ctrl+C arrête la planification de nouvelles applications de test et demande l’annulation coopérative. Appuyez de nouveau sur Ctrl+C pour arrêter immédiatement les processus enfants. Une exécution abandonnée s’arrête avec le code 3.

La sortie de l’hôte de test en direct nécessite un hôte MTP qui prend en charge le protocole 1.1 ou une version ultérieure. Les anciens hôtes conservent la sortie capturée et relecture pour un module ayant échoué. À compter de .NET 11 Preview 7, les résumés d’échecs tronquent la sortie standard capturée plus de 40 lignes jusqu’aux 30 premières et 10 dernières lignes ; les journaux de diagnostic conservent la sortie complète.

Pour les exécutions multimodèles, dotnet test évalue le résultat de test zéro dans l’exécution complète à partir de .NET 11 Preview 7. Un module sans test n’échoue pas à l’exécution si un autre module exécute correctement des tests, sauf si une stratégie de test minimale explicite nécessite davantage de tests.

Résultats et artefacts

Lorsque la disposition de sortie des artefacts du SDK est activée, .NET 11 RC 1 et versions ultérieures placent les rapports MTP, les fichiers de couverture et les diagnostics par <ArtifactsPath>/test/<project>/<pivot> défaut. Une priorité explicite --results-directory ou --results-directory-layout prioritaire.

À compter de .NET 11 RC 1 et MTP 2.4, les extensions compatibles peuvent post-traiter des artefacts à partir d’une exécution multimodèle. Par exemple, l’extension TRX peut créer un rapport fusionné tout en conservant les rapports par module. Pour connaître les exigences relatives à l’extension et aux rapports, consultez les rapports de test MTP.

Transférer des arguments à l’application de test

dotnet test transfère tout jeton qu’il ne reconnaît pas à l’application de test. Lorsqu’une option reconnue apparaît entre un nom d’option non reconnu et sa valeur, la suppression de l’option reconnue peut modifier la façon dont les jetons de reste sont liés aux options dans l’application de test. Pour éviter cette ambiguïté, placez les arguments d’application de test après un littéral --:

dotnet test --results-directory TestResults -- --report-trx --report-trx-filename A.trx

L’exemple précédent nécessite le Microsoft.Testing.Extensions.TrxReport package, soit en tant que référence de package directe, soit par le biais d’une configuration du Kit de développement logiciel (SDK) de test qui l’inclut.

Le même comportement d’analyseur s’applique à dotnet run et dotnet build. Pour obtenir un exemple détaillé, consultez Transférer des arguments à l’application dans la dotnet run référence.

Minimums d’exécution et par module

Pour --minimum-expected-tests, le -- séparateur détermine l’étendue de l’option :

  • Les arguments avant-- sont globaux. L’orchestrateur dotnet test les interprète pour toute l’exécution.
  • Les arguments après-- sont locaux. dotnet test les transfère à chaque module de test, de sorte que chaque module les applique indépendamment.

Étant donné qu’elle --minimum-expected-tests est disponible dans les deux étendues, vous pouvez exiger un minimum pour l’ensemble de l’exécution, pour chaque module ou les deux :

dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2

La commande précédente nécessite au moins 5 tests sur l’ensemble de l’exécution et au moins 2 tests dans chaque module de test.

Les deux étendues comptent les tests ignorés différemment :

Scope Les tests ignorés sont-ils comptabilisés vers le minimum ?
Global Yes. Le dotnet test total agrégé inclut des tests ignorés.
Par module Non. MTP exclut les tests ignorés du nombre de tests exécutés.

À compter du SDK .NET 11, le verdict de test zéro pour l’exécution entière est décidé une fois à partir des résultats agrégés. Un module qui ne correspond à aucun test, par exemple en raison d’un --test-modules résultat global --filter, quitte avec le code 8 (ZeroTests), mais ce code est normalisé pour réussir avant que les résultats ne soient agrégés. Par conséquent, un seul module vide n’échoue pas toute l’exécution, bien que le module conserve son Exit code: 8 diagnostic dans la sortie pour une visibilité.

MTP 4.3.0 et versions ultérieures fournissent --zero-tests-policy <allow-skipped|strict>. La valeur par défaut, permet allow-skippedà un module ignoré de réussir. La strict valeur traite les tests ignorés comme n’étant pas exécutés, un module ignoré s’arrête avec le code 8. Passez l’option après -- pour la transférer à chaque module de test :

dotnet test -- --zero-tests-policy strict

Lorsque vous ne définissez pas un minimum global, le kit de développement logiciel (SDK) .NET 11 détermine le verdict de test zéro d'exécution entier séparément. Une exécution entière ignorée s’arrête avec le code 8, quelle que soit la valeur par module --zero-tests-policy .

Lorsque vous spécifiez --minimum-expected-tests et que le minimum n’est pas atteint, l’exécution échoue avec le code de sortie 9 (MinimumExpectedTestsPolicyViolation). Ce code est distinct de 8 afin qu’un minimum global ou par module plus strict ne soit pas confondu avec un module vide. Pour qu’un minimum par module retourne le code 9 lorsque le module exécute zéro test, le module de test doit utiliser MTP 4.4.0 ou une version ultérieure.

Note

--minimum-expected-tests 0 n’est pas valide. Pour supprimer le code de sortie de zero-tests, utilisez --ignore-exit-code 8.

À compter de .NET 11 Preview 6, --tlet --terminallogger--tlp sont transférés à MSBuild au lieu de l’application de test. À compter de .NET 12 Preview 1, les formulaires reconnus -mt et -multiThreaded les formulaires sont également transférés à MSBuild. Pour passer une option d’application avec l’un de ces noms, placez-la après --.

Passez des options en mode d’exécution telles que --help et --list-tests directement à dotnet test. À compter de .NET 11 Preview 6, le Kit de développement logiciel (SDK) valide le mode d’exécution négocié avec l’application de test. Si un profil de lancement ou TestingPlatformCommandLineArguments injecte l’une de ces options, l’opération du SDK demandée et l’opération d’application ne correspondent pas, et l’exécution échoue avec un diagnostic.

Examples

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

    dotnet test

  • Exécutez les tests dans le TestProject project :

    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 tous les projets de test référencés par un projet de traversée avec .NET 11 Preview 7 ou version ultérieure :

    dotnet test dirs.proj

  • Répertoriez les tests au format JSON avec .NET 11 Preview 7 ou version ultérieure :

    dotnet test --list-tests json

  • Exécutez une application de test MTP basée sur un fichier C# avec .NET 12 Preview 1 ou version ultérieure :

    dotnet test App.Tests.cs

  • Exécutez les tests dans le répertoire actif avec l’extension Microsoft Couverture du code. L’application de test doit référencer Microsoft.Testing.Extensions.CodeCoveragedirectement ou par le biais d’une configuration du Kit de développement logiciel (SDK) de test qui l’inclut :

    dotnet test --coverage

  • Exécutez les tests et stockez les résultats dans un répertoire spécifique :

    dotnet test --results-directory ./TestResults

  • Exécutez les tests avec la sortie de diagnostic dans un répertoire spécifique :

    dotnet test --diagnostic-output-directory ./Diagnostics

  • Exécutez les tests pour vous assurer qu’au moins 10 tests sont exécutés :

    dotnet test --minimum-expected-tests 10

  • Exiger au moins 5 tests sur l’ensemble de l’exécution et au moins 2 tests dans chaque module de test :

    dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2

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

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

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

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

Voir aussi

  • Last updated on