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 toutes les options pour les VSTest.Console.exe et les descriptions courtes de celles-ci. Vous pouvez voir un résumé similaire en tapant VSTest.Console/? sur une ligne de commande.
| 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,testMethod2L’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. |
| /Enablecodecoverage | Active codeCoverage de l’adaptateur de diagnostic de données dans l’exécution de test. Les paramètres par défaut sont utilisés s’ils ne sont pas spécifiés à l’aide du 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. |
| /UseVsixExtensions | Cette option rend le processus vstest.console.exe utiliser ou ignorer les extensions VSIX installées (le cas échéant) dans l’exécution de test. Cette option est déconseillée. À partir de la prochaine version majeure de Visual Studio, cette option peut être supprimée. Passez à l’utilisation d’extensions rendues disponibles en tant que package NuGet. Exemple : /UseVsixExtensions:true |
| /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’utilisation de la plateforme donnée, au lieu de la plateforme déterminée à partir du runtime actuel. Cette option est en mesure de forcer uniquement les plateformes x86 et x64 sur Windows. L’option ARM est interrompue et entraîne la mise en place de x64 sur la plupart des systèmes. Ne spécifiez pas cette option pour s’exécuter sur les runtimes qui ne figurent pas dans la liste des valeurs valides telles que ARM64. Les valeurs valides sont x86, x64 et ARM. |
| /Framework : [version du framework] | Version .NET cible à utiliser pour l’exécution de test. Les exemples de valeurs sont Framework35, Framework40, Framework45, FrameworkUap10, .NETCoreApp,Version=v1.1.TargetFrameworkAttribute est utilisé pour détecter automatiquement cette option à partir de votre assembly, et la valeur par défaut est Framework40 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:framework40 |
| /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. |
| / ? | 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>] |
| /ListTests :[ nom de fichier] | Répertorie les tests découverts à partir du conteneur de test donné. Remarque : l’option /TestCaseFilters n’a aucun effet lors de la description des tests ; elle contrôle uniquement les tests qui s’exécutent. |
| /ListDiscoverers | Répertorie les détecteurs de test installés. |
| /ListExecutors | Répertorie les exécuteurs de test installés. |
| /ListLoggers | Répertorie les enregistreurs d’événements de test installés. |
| /ListSettingsProviders | Répertorie les fournisseurs de paramètres de test installés. |
| /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. Pour plus d’informations, consultez collecteur de données blâme. |
| /Diag :[ nom de fichier] | Écrit les journaux de trace de diagnostic dans le fichier spécifié. |
| /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. |
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>
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