options de ligne de commande VSTest.Console.exe

VSTest.Console.exe est l’outil en ligne de commande pour exécuter des tests. Vous pouvez spécifier plusieurs options dans n’importe quel ordre sur la ligne de commande. Ces options sont répertoriées dans options de ligne de commande général.

Note

L’adaptateur MSTest dans Visual Studio fonctionne également en mode hérité (équivalent à l’exécution de tests avec mstest.exe) pour la compatibilité. En mode hérité, il ne peut pas tirer parti de la fonctionnalité TestCaseFilter. L’adaptateur peut basculer en mode hérité lorsqu’un testsettings fichier est spécifié, forcelegacymode est défini sur true dans un runsettings fichier, ou à l’aide d’attributs tels que HostType.

Pour exécuter des tests automatisés sur une machine basée sur une architecture ARM, vous devez utiliser VSTest.Console.exe.

Ouvrez invite de commandes développeur pour utiliser l’outil en ligne de commande, ou vous pouvez trouver l’outil dans %Program Files(x86)%\Microsoft Visual Studio\<version>\<edition>\common7\ide\CommonExtensions\<Platform | Microsoft>.

Options générales de ligne de commande

Le tableau suivant répertorie les options couramment utilisées pour lesVSTest.Console.exe et les descriptions courtes d’entre elles. Vous pouvez voir un résumé similaire en tapant VSTest.Console/? sur une ligne de commande. Pour obtenir la référence complète, y compris les commutateurs internes et hérités qui ne sont pas répertoriés ici, consultez vstest.console.exe options de ligne de commande et spécifiquement omises dans le référentiel vstest.

Option Description
[ noms de fichiers de test] Exécutez des tests à partir des fichiers spécifiés. Séparez plusieurs noms de fichiers de test avec des espaces.
Exemples : mytestproject.dll, mytestproject.dll myothertestproject.exe
/Settings :[ nom de fichier] Exécutez des tests avec des paramètres supplémentaires tels que les collecteurs de données. Pour plus d’informations, consultez Configurer des tests unitaires à l’aide d’un fichier .runsettings
Exemple : /Settings:local.runsettings
/Tests :[ nom de test] Exécutez des tests avec des noms qui contiennent les valeurs fournies. Cette commande correspond au nom de test complet, y compris l’espace de noms. Pour fournir plusieurs valeurs, séparez-les par des virgules.
Exemple : /Tests:TestMethod1,testMethod2
L’option de ligne de commande /Tests ne peut pas être utilisée avec l’option de ligne de commande /TestCaseFilter .
/Parallel Spécifie que les tests doivent être exécutés en parallèle. Par défaut, jusqu’à tous les cœurs disponibles sur l’ordinateur peuvent être utilisés. Vous pouvez configurer le nombre de cœurs à utiliser dans un fichier de paramètres.
/InIsolation Exécute les tests dans un processus isolé.
Cette isolation rend le processus vstest.console.exe moins susceptible d’être arrêté sur une erreur dans les tests, mais les tests peuvent s’exécuter plus lentement.
/TestAdapterPath :[path] Force le processus vstest.console.exe à utiliser des adaptateurs de test personnalisés à partir d’un chemin d’accès spécifié (le cas échéant) dans l’exécution de test.
Exemple : /TestAdapterPath:[pathToCustomAdapters]
/Platform :[type de plateforme] Force l’architecture de plateforme donnée à utiliser, au lieu de la plateforme déterminée à partir du runtime actuel. Les valeurs ne respectent pas la casse ; les valeurs acceptées sont x86, , ARMx64, ARM64RiscV64S390xPpc64leet .LoongArch64
Sur Windows, seuls les systèmes x86 et x64 peuvent être forcés de manière fiable ; en spécifiant des ARM résultats x64 sur la plupart des systèmes. Ne spécifiez pas cette option pour s’exécuter sur un runtime qui n’est pas dans la liste des valeurs valides.
/Framework : [version du framework] Version .NET cible à utiliser pour l’exécution de test.
Les formulaires courts du framework moderne sont acceptés et analysés par l’analyseur de framework NuGet, par exemple net48, net6.0ou net10.0 (ainsi que les formulaires longs tels que .NETFramework,Version=v4.8 et .NETCoreApp,Version=v10.0).
Les alias héritésFramework35, , Framework45Framework40, FrameworkCore10et FrameworkUap10 sont également acceptés.
TargetFrameworkAttribute est utilisé pour détecter automatiquement cette option à partir de votre assembly et par Framework40 défaut lorsque l’attribut n’est pas présent. Vous devez spécifier cette option explicitement si vous supprimez le TargetFrameworkAttribute de vos assemblys .NET Core.
Si l’infrastructure cible est spécifiée comme Framework35, les tests s’exécutent en mode de compatibilité CLR 4.0.
Exemple : /Framework:net8.0
/TestCaseFilter :[expression] Exécutez des tests qui correspondent à l’expression donnée.
<expression> est de la propriété de format <>=<valeur>[|<Expression>].
Exemple : /TestCaseFilter:"Priority=1"
Exemple : /TestCaseFilter:"TestCategory=Nightly|FullyQualifiedName=Namespace.ClassName.MethodName"
L’option de ligne de commande /TestCaseFilter ne peut pas être utilisée avec l’option de ligne de commande /Tests .
Pour plus d’informations sur la création et l’utilisation d’expressions, consultez filtre TestCase. Lorsque vous tapez un filtre directement dans un interpréteur de commandes, consultez les expressions de filtre d’échappement dans l’interpréteur de commandes.
/Environment :[NAME]=[VALUE] Définit la valeur d’une variable d’environnement pour le processus hôte de test. Crée la variable si elle n’existe pas et la remplace si elle le fait. Cette option implique /InIsolation et force les tests à s’exécuter dans un processus isolé. Spécifiez l’option plusieurs fois pour définir plusieurs variables. Forme courte : /e.
Exemple : /e:VARIABLE1=VALUE1
/ ? Affiche les informations d’utilisation.
/Logger :[ uri/friendlyname] Spécifiez un enregistreur d’événements pour les résultats des tests. Spécifiez le paramètre plusieurs fois pour activer plusieurs enregistreurs d’événements.
Exemple : pour journaliser les résultats dans un fichier de résultats de test Visual Studio (TRX), utilisez
/Logger :trx
[ ; LogFileName=<Defaults to unique file name>]
Utilisez LogFilePrefix=<prefix> plutôt que de LogFileName conserver un fichier séparé et horodaté par exécution. LogFileName définit un nom explicite et remplace le fichier précédent, tandis que ce n’est pas le cas LogFilePrefix .
Pour plus d’informations, consultez l’exemple de journalisation.
/ListTests :[ nom de fichier] Répertorie les tests découverts à partir du conteneur de test donné. Forme courte : /lt.
Remarque : l’option /TestCaseFilter n’a aucun effet lors de la description des tests ; elle contrôle uniquement les tests qui s’exécutent.
/Blame Exécute les tests en mode blâme. Cette option est utile pour isoler les tests problématiques qui provoquent le blocage de l’hôte de test. Lorsqu’un incident est détecté, il crée un fichier de séquence dans TestResults/<Guid>/<Guid>_Sequence.xml qui capture l’ordre des tests exécutés avant le blocage.
Vous pouvez également collecter un blocage ou un vidage de blocage, par exemple /Blame:CollectDump;DumpType=full ou /Blame:CollectHangDump;TestTimeout=90m;HangDumpType=mini. Les commutateurs équivalents dotnet test sont --blame-crash et --blame-hang.
Pour connaître la matrice d’options complète et les exigences de collecte de vidage, consultez Le collecteur de données de blâme.
/Diag :[ nom de fichier] Écrit les journaux de trace de diagnostic dans le fichier spécifié.
Définissez le niveau de trace avec /Diag:<file name>;tracelevel=<off\|error\|warning\|info\|verbose> (la valeur par défaut est verbose).
/ResultsDirectory :[chemin d’accès] Le répertoire des résultats de test est créé dans le chemin spécifié s’il n’existe pas.
Exemple : /ResultsDirectory:<pathToResultsDirectory>
/ParentProcessId :[parentProcessId] ID de processus du processus parent responsable du lancement du processus actuel.
/Port :[port] Port de connexion de socket et réception des messages d’événement.
/Collect :[dataCollector friendlyName] Active le collecteur de données pour l’exécution de test. Plus d’informations.
@[file] Lit les options supplémentaires du fichier de réponse spécifié. Les arguments du fichier sont séparés par des espaces blancs (espaces ou lignes nouvelles) et des guillemets sont pris en charge. Les options peuvent donc s’étendre sur plusieurs lignes.
Exemple : vstest.console.exe @options.rsp

Pourboire

Les options et les valeurs ne respectent pas la casse.

Exemples

La syntaxe de l’exécution de vstest.console.exe est la suivante :

vstest.console.exe [TestFileNames] [Options]

Par défaut, la commande retourne 0 lorsqu’elle se ferme normalement, même si aucun test n’est détecté. Si vous souhaitez retourner une valeur non nulle si aucun test n’est détecté, utilisez <TreatNoTestsAsError>true</TreatNoTestsAsError> option runsettings.

La commande suivante exécute vstest.console.exe pour la bibliothèque de tests myTestProject.dll:

vstest.console.exe myTestProject.dll

La commande suivante exécute vstest.console.exe avec plusieurs fichiers de test. Séparez les noms de fichiers de test avec des espaces :

vstest.console.exe myTestFile.dll myOtherTestFile.dll

La commande suivante s’exécute vstest.console.exe avec plusieurs options. Il exécute les tests dans le fichier myTestFile.dll dans un processus isolé et utilise les paramètres spécifiés dans le fichier Local.RunSettings. En outre, il exécute uniquement les tests marqués « Priority=1 » et enregistre les résultats dans un fichier .trx.

vstest.console.exe myTestFile.dll /Settings:Local.RunSettings /InIsolation /TestCaseFilter:"Priority=1" /Logger:trx

La commande suivante exécute vstest.console.exe avec l’option /blame de la bibliothèque de tests myTestProject.dll:

vstest.console.exe myTestFile.dll /blame

Si un incident d’hôte de test s’est produit, le fichier sequence.xml est généré. Le fichier contient des noms qualifiés complets des tests dans leur séquence d’exécution jusqu’à et y compris le test spécifique qui s’exécutait au moment de l’incident.

S’il n’existe aucun blocage de l’hôte de test, le fichier sequence.xml ne sera pas généré.

Exemple de fichier sequence.xml généré :

<?xml version="1.0"?>
<TestSequence>
  <Test Name="TestProject.UnitTest1.TestMethodB" Source="D:\repos\TestProject\TestProject\bin\Debug\TestProject.dll" />
  <Test Name="TestProject.UnitTest1.TestMethodA" Source="D:\repos\TestProject\TestProject\bin\Debug\TestProject.dll" />
</TestSequence>

Dans ce cas, le <Test Name> dernier est le test qui s’exécutait au moment de l’incident.

Codes de sortie

vstest.console.exe retourne l’un des deux codes de sortie :

Code Meaning
0 Opération réussie. L’opération demandée s’est terminée et, pour une exécution de test, tous les tests exécutés ont réussi.
1 Échec. Par exemple, un ou plusieurs tests ont échoué, une erreur d’exécution a été signalée, la ligne de commande n’était pas valide ou manquante, une source de test n’a pas pu être chargée ou l’exécution a été abandonnée ou annulée.

Le processus ne retourne jamais d’autre valeur. Lorsque vous exécutez des testsdotnet test, le sdk .NET expose un code de sortie non nul lorsque l’exécution échoue de la même façon.

Lorsque la découverte ne trouve aucun test correspondant, l’exécuteur imprime un avertissement plutôt qu’une erreur, et retourne 0toujours par défaut . Pour effectuer une exécution qui découvre ou sélectionne zéro test retourne 1 à la place, définissez <TreatNoTestsAsError>true</TreatNoTestsAsError> dans l’élément RunConfiguration de votre fichier .runsettings . Pour plus d’informations, consultez Configurer des tests unitaires à l’aide d’un fichier .runsettings.

Expressions de filtre d’échappement dans l’interpréteur de commandes

Une expression /TestCaseFilter est analysée à la fois par votre interpréteur de commandes et la plateforme de test. Certains caractères ont donc besoin d’une échappement spécifique à l’interpréteur de commandes avant quevstest.console.exe les reçoive. Le guillemet de l’expression entière, comme dans les exemples précédents de cet article, évite la plupart des problèmes. Les cas suivants nécessitent des soins supplémentaires :

  • PowerShell : La virgule (,) est l’opérateur de tableau et le point-virgule (;) est un séparateur d’instructions. Citez l’expression de filtre entière afin qu’elle soit transmise littéralement, par exemple /TestCaseFilter:"FullyQualifiedName=MyNamespace.MyClass.MyMethod".

  • Bash et zsh (Linux et macOS) : échappement ! avec une barre oblique inverse lorsque vous utilisez l’opérateur !~ (non contient), par exemple --filter FullyQualifiedName\!~IntegrationTests avec dotnet test. Citez également les valeurs qui contiennent des caractères ayant une signification spéciale pour l’interpréteur de commandes, par <exemple, >ou , dans une liste d’arguments de type générique :

    dotnet test --filter "FullyQualifiedName=MyNamespace.MyClass<Type1,Type2>.MyMethod"

Pour obtenir la référence de filtrage complète et les propriétés prises en charge par framework de test, consultez le filtre TestCase.

Exemple de journalisation

Chaque enregistreur d’événements définit ses propres paramètres. Contrairement à trx, l’enregistreur d’événements de console vous permet de définir le niveau de détail. Pour plus d’informations, tapez VSTest.Console/? sur la ligne de commande.

Voici un exemple pour l’enregistreur d’événements de console :

vstest.console.exe myTestFile.dll /logger:console;verbosity=detailed

Les niveaux de détail pris en charge incluent silencieux, minimal, normal et détaillé.

Dans PowerShell, vous devez utiliser des guillemets :

vstest.console.exe myTestFile.dll /logger:"console;verbosity=detailed"

Pour obtenir la liste complète des enregistreurs d’événements disponibles, ainsi que des instructions pour la création de votre propre enregistreur d’événements, consultez les résultats des tests de création de rapports dans le référentiel vstest.

Exemple UWP

Pour UWP, le fichier appxrecipe doit être référencé au lieu d’une DLL.

vstest.console.exe /Logger:trx /Platform:x64 /framework:frameworkuap10 UnitTestsUWP\bin\x64\Release\UnitTestsUWP.build.appxrecipe

Variables d’environnement

La plateforme de test reconnaît plusieurs variables d’environnement. Voici les éléments les plus utiles lorsque vous exécutez des tests à partir de la ligne de commande. Pour obtenir la liste complète, consultez les variables d’environnement comprises par la plateforme de test dans le référentiel vstest.

Variable Description
VSTEST_CONNECTION_TIMEOUT Délai d’expiration, en secondes, pour établir des connexions entre les composants de la plateforme de test (vstest.console.exe, testhost et collecteur de données). La valeur par défaut est 90. Augmentez-le sur les ordinateurs lents ou lorsque la latence réseau provoque des délais d’expiration de connexion.
VSTEST_DIAG Active la journalisation des diagnostics et spécifie le chemin d’accès au fichier journal. Équivalent à l’option /Diag .
VSTEST_DIAG_VERBOSITY Définit la détail de la journalisation des diagnostics quand VSTEST_DIAG elle est activée. Les valeurs valides sont Verbose, Info, Warninget Error (la valeur par défaut est Verbose).
VSTEST_HOST_DEBUG Définissez sur n’importe quelle valeur non vide pour activer le débogage du processus testhost.
VSTEST_RUNNER_DEBUG Définissez sur n’importe quelle valeur non vide pour activer le débogage de l’exécuteur (vstest.console.exe).
VSTEST_DUMP_PATH Remplace le répertoire par défaut dans lequel les vidages sur incident sont stockés.
VSTEST_DUMP_FORCEPROCDUMP Définissez sur n’importe quelle valeur non vide pour forcer ProcDump à utiliser pour la collecte de vidages sur incident.
VSTEST_DISABLE_UTF8_CONSOLE_ENCODING Définissez cette option pour 1 désactiver la définition de l’encodage UTF-8 sur la sortie de la console.
VSTEST_CONSOLE_PATH Chemin d'accès au fichier exécutable vstest.console.exe utilisé par l'application de transfert du dotnet test KIT de développement logiciel (SDK) .NET. Équivaut au -p:VSTestConsolePath moment de l’exécution dotnet test sur un projet.

Contenu connexe

  • Last updated on