Partager via


dotnet vstest

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

Important

La dotnet vstest commande est remplacée par dotnet test, qui peut désormais être utilisée pour exécuter des assemblys. Consultez le test dotnet.

Nom

dotnet vstest - Exécute des tests à partir des assemblys spécifiés.

Synopsis

dotnet vstest [<TEST_FILE_NAMES>] [--Blame] [--Diag <PATH_TO_LOG_FILE>]
    [--Framework <FRAMEWORK>] [--InIsolation] [-lt|--ListTests <FILE_NAME>]
    [--logger <LOGGER_URI/FRIENDLY_NAME>] [--Parallel]
    [--ParentProcessId <PROCESS_ID>] [--Platform] <PLATFORM_TYPE>
    [--Port <PORT>] [--ResultsDirectory<PATH>] [--Settings <SETTINGS_FILE>]
    [--TestAdapterPath <PATH>] [--TestCaseFilter <EXPRESSION>]
    [--Tests <TEST_NAMES>] [[--] <args>...]

dotnet vstest -?|--Help

Descriptif

La dotnet vstest commande exécute l’application VSTest.Console en ligne de commande pour exécuter des tests unitaires automatisés.

Arguments

  • TEST_FILE_NAMES

    Exécutez des tests à partir des assemblys spécifiés. Séparez plusieurs noms d’assembly de test avec des espaces. Les caractères génériques sont pris en charge.

Options

  • --Blame

    Exécute les tests en mode responsable. Cette option est utile pour isoler les tests problématiques provoquant un blocage de l’hôte de test. Il crée un fichier de sortie dans le répertoire actif en tant que Sequence.xml qui capture l’ordre d’exécution des tests avant le blocage.

  • --Diag <PATH_TO_LOG_FILE>

    Active les journaux détaillés pour la plateforme de test. Les journaux sont écrits dans le fichier fourni.

  • --Framework <FRAMEWORK>

    Version cible du .NET Framework utilisée pour l’exécution de test. Un exemple de valeur valide est .NETFramework,Version=v7.0. D’autres valeurs prises en charge sont Framework40, , Framework45FrameworkCore10et FrameworkUap10.

  • --InIsolation

    Exécute les tests dans un processus isolé. Cela rend vstest.console.exeprocessus moins susceptible d’être arrêté sur une erreur dans les tests, mais les tests peuvent s’exécuter plus lentement.

  • -lt|--ListTests <FILE_NAME>

    Répertorie tous les tests découverts à partir du conteneur de test donné.

  • --logger <LOGGER_URI/FRIENDLY_NAME>

    Spécifiez un enregistreur d’événements pour les résultats des tests.

    • Pour publier les résultats des tests sur Team Foundation Server, utilisez le fournisseur d’enregistreurs d’événements TfsPublisher :

      /logger:TfsPublisher;
          Collection=<team project collection url>;
          BuildName=<build name>;
          TeamProject=<team project name>
          [;Platform=<Defaults to "Any CPU">]
          [;Flavor=<Defaults to "Debug">]
          [;RunTitle=<title>]
      
    • Pour journaliser les résultats dans un fichier de résultats de test Visual Studio (TRX), utilisez le fournisseur d’enregistreurs d’événements trx . Ce commutateur crée un fichier dans le répertoire des résultats de test avec un nom de fichier journal donné. Si LogFileName ce n’est pas le cas, un nom de fichier unique est créé pour contenir les résultats des tests.

      /logger:trx [;LogFileName=<Defaults to unique file name>]
      
  • --Parallel

    Exécuter les tests en parallèle. Par défaut, tous les cœurs disponibles sur l’ordinateur sont disponibles pour une utilisation. Spécifiez un nombre explicite de cœurs en définissant la MaxCpuCount propriété sous le RunConfiguration nœud du fichier runsettings .

  • --ParentProcessId <PROCESS_ID>

    ID de processus du processus parent responsable du lancement du processus actuel.

  • --Platform <PLATFORM_TYPE>

    Architecture de plateforme cible utilisée pour l’exécution des tests. Les valeurs valides sont x86, x64et ARM.

  • --Port <PORT>

    Spécifie le port de la connexion de socket et la réception des messages d’événement.

  • --ResultsDirectory:<PATH>

    Le répertoire des résultats de test est créé dans le chemin spécifié s’il n’existe pas.

  • --Settings <SETTINGS_FILE>

    Paramètres à utiliser lors de l’exécution de tests.

  • --TestAdapterPath <PATH>

    Utilisez des adaptateurs de test personnalisés à partir d’un chemin d’accès donné (le cas échéant) dans l’exécution de test.

  • --TestCaseFilter <EXPRESSION>

    Exécutez des tests qui correspondent à l’expression donnée. <EXPRESSION> est au format <property>Operator<value>[|&<EXPRESSION>], où l’opérateur est l’un des =, !=ou ~. L’opérateur ~ a la sémantique « contains » et s’applique aux propriétés de chaîne comme DisplayName. Les parenthèses () sont utilisées pour regrouper les sous-expressions. Pour plus d’informations, consultez le filtre TestCase.

  • --Tests <TEST_NAMES>

    Exécutez des tests avec des noms qui correspondent aux valeurs fournies. Séparez les valeurs multiples à l'aide de virgules.

  • -?|--Help

    Imprime une aide courte pour la commande.

  • @<file>

    Lit le fichier de réponse pour plus d’options.

  • args

    Spécifie des arguments supplémentaires à passer à l’adaptateur. Les arguments sont spécifiés en tant que paires nom-valeur du formulaire <n>=<v>, où <n> est le nom de l’argument et <v> la valeur de l’argument. Utilisez un espace pour séparer plusieurs arguments.

Examples

Exécutez des tests dans mytestproject.dll:

dotnet vstest mytestproject.dll

Exécutez des tests dans mytestproject.dll, exportez vers un dossier personnalisé avec un nom personnalisé :

dotnet vstest mytestproject.dll --logger:"trx;LogFileName=custom_file_name.trx" --ResultsDirectory:custom/file/path

Exécutez des tests dans mytestproject.dll et myothertestproject.exe:

dotnet vstest mytestproject.dll myothertestproject.exe

Exécuter des TestMethod1 tests :

dotnet vstest /Tests:TestMethod1

Exécuter TestMethod1 et TestMethod2 tester :

dotnet vstest /Tests:TestMethod1,TestMethod2

Voir aussi