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 un ordre quelconque dans la ligne de commande. Ces options sont répertoriées dans Options de ligne de commande générales.
Notes
L’adaptateur MSTest de Visual Studio fonctionne également en mode hérité (équivalent de 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é quand un fichier testsettings est spécifié, que forcelegacymode a la valeur true dans un fichier runsettings, ou à l’aide d’attributs comme HostType.
Pour exécuter des tests automatisés sur un ordinateur basé sur une architecture ARM, vous devez utiliser VSTest.Console.exe.
Ouvrez l’invite de commandes développeur pour utiliser l’outil en ligne de commande, ou vous trouverez l’outil dans %Program Files(x86)%\Microsoft Visual Studio\<version>\<edition>\common7\ide\CommonExtensions\<Platform | Microsoft>.
Options de ligne de commande générales
Le tableau suivant répertorie toutes les options de VSTest.Console.exe, ainsi que leurs brèves descriptions. Vous pouvez voir un résumé semblable en tapant VSTest.Console/? sur une ligne de commande.
| Option | Description |
|---|---|
| [noms de fichiers de test] | Exécutez les tests à partir des fichiers spécifiés. Séparez les noms de fichiers de test par des espaces. Exemples : mytestproject.dll, mytestproject.dll myothertestproject.exe |
| /Settings:[nom de fichier] | Exécutez les tests avec d'autres paramètres 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 du test] | Exécutez les tests avec les 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, tout ou partie des cœurs disponibles sur la machine peuvent être utilisés. Vous pouvez configurer le nombre de cœurs à utiliser dans un fichier de paramètres. |
| /Enablecodecoverage | Active l'adaptateur de données de diagnostic CodeCoverage dans la série de tests. 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é. En raison de cette isolation, il est moins probable que le processus vstest.console.exe soit arrêté sur une erreur dans les tests, mais les tests peuvent s’exécuter plus lentement. |
| /UseVsixExtensions | Grâce à cette option, le processus vstest.console.exe utilise ou ignore les extensions VSIX installées (le cas échéant) dans la série de tests. Cette fonction est déconseillée. À compter de la prochaine version majeure de Visual Studio, cette option peut être supprimée. Envisagez d’utiliser des extensions disponibles en tant que package NuGet. Exemple : /UseVsixExtensions:true |
| /TestAdapterPath:[chemin] | Force le processus vstest.console.exe à utiliser des adaptateurs de test personnalisés à partir d’un chemin spécifié (le cas échéant) dans la série de tests. Exemple : /TestAdapterPath:[pathToCustomAdapters] |
| /Platform:[type de plateforme] | Force l’utilisation de la plateforme donnée à la place de la plateforme déterminée à partir du runtime actuel. Cette option peut forcer uniquement les plateformes x86 et x64 sur Windows. L’option ARM est interrompue et entraîne l’utilisation de x64 sur la plupart des systèmes. Ne spécifiez PAS cette option pour une exécution sur des runtimes qui ne figurent pas dans la liste des valeurs valides comme ARM64. Les valeurs valides sont x86, x64 et ARM. |
| /Framework: [version de .Net Framework] | Version de .NET cible à utiliser pour l’exécution des tests. Les valeurs possibles sont Framework35, Framework40, Framework45, FrameworkUap10 et .NETCoreApp,Version=v1.1.TargetFrameworkAttribute est utilisé pour détecter automatiquement cette option à partir de votre assembly et a la valeur Framework40 par défaut lorsque l’attribut n’est pas présent. Vous devez spécifier cette option explicitement si vous supprimez targetFrameworkAttribute de vos assemblys .NET Core.Si la version cible de.Net Framework est spécifiée comme étant Framework35, les tests s’exécutent en « mode de compatibilité » CLR 4.0. Exemple : /Framework:framework40 |
| /TestCaseFilter:[expression] | Exécutez les tests qui correspondent à l'expression donnée. <Expression> est au format <property>=<value>[|<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 des informations sur l’utilisation. |
| /Logger:[uri/nom_convivial] | Spécifiez un journal pour les résultats de tests. Spécifiez le paramètre plusieurs fois pour activer plusieurs enregistreurs d’événements. Par exemple, pour stocker les résultats dans les fichiers de résultats des tests de Visual Studio (TRX), utilisez /Logger:trx [;LogFileName=<Nom de fichier unique par défaut>] |
| /ListTests:[nom de fichier] | Répertorie les tests détectés dans le conteneur de tests donné. Remarque : L’option /TestCaseFilters n’a aucun effet lors de la liste des tests ; elle contrôle uniquement les tests qui sont exécutés. |
| /ListDiscoverers | Répertorie les découvreurs de test installés. |
| /ListExecutors | Répertorie les exécuteurs de test installés. |
| /ListLoggers | Répertorie les journaux de test installés. |
| /ListSettingsProviders | Répertorie les fournisseurs de paramètres installés. |
| /Blame | Exécute les tests en mode responsable. Cette option permet d’isoler les tests responsables des incidents sur l’hôte de test. Lorsqu’un incident est détecté, elle crée dans TestResults/<Guid>/<Guid>_Sequence.xml un fichier de séquence qui enregistre l’ordre des tests exécutés avant l’incident. Pour plus d’informations, voir Collecteur de données Blame. |
| /Diag:[nom de fichier] | Écrit les journaux de trace de diagnostic dans le fichier spécifié. |
| /ResultsDirectory:[chemin] | Un répertoire de résultats de test sera créé dans le chemin d’accès spécifié s’il n’en existe pas. Exemple : /ResultsDirectory:<pathToResultsDirectory> |
| /ParentProcessId:[ID_processus_parent] | ID du processus parent chargé de lancer le processus actif. |
| /Port:[port] | Port de connexion de socket et de réception des messages d’événement. |
| /Collect:[nom_convivial collecteur_de_données] | Active le collecteur de données pour la série de tests. Informations complémentaires. |
Conseil
Les options et les valeurs ne respectent pas la casse.
Exemples
La syntaxe pour exécuter vstest.console.exe est la suivante :
vstest.console.exe [TestFileNames] [Options]
Par défaut, la commande retourne 0 lorsqu’elle se termine normalement, même si aucun test n’est détecté. Si vous souhaitez retourner une valeur autre que zéro si aucun test n’est détecté, utilisez l’option runsettings <TreatNoTestsAsError>true</TreatNoTestsAsError>.
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 par des espaces :
vstest.console.exe myTestFile.dll myOtherTestFile.dll
La commande suivante exécute vstest.console.exe avec plusieurs options. Elle exécute les tests du fichier myTestFile.dll dans un processus isolé et utilise des paramètres spécifiés dans le fichier Local.RunSettings. En outre, elle n’exécute que les tests marqués « Priority=1 » et journalise 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 test myTestProject.dll :
vstest.console.exe myTestFile.dll /blame
Si un plantage de l’hôte de test s’est produit, le fichier sequence.xml est généré. Le fichier contient les noms complets des tests dans leur séquence d’exécution jusqu’à et y compris le test spécifique qui était en cours d’exécution au moment de l’incident.
En l’absence de plantage de l’hôte de test, le fichier sequence.xml n’est 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