Partager via

Vue d’ensemble de Microsoft.Testing.Platform

  • Article

Microsoft.Testing.Platform est une alternative légère et portable à VSTest pour exécuter des tests dans tous les contextes, notamment les pipelines d’intégration continue (CI), l’interface CLI, l’Explorateur de tests Visual Studio et l’Explorateur de texte VS Code. Microsoft.Testing.Platform est intégré directement dans vos projets de test et il n’existe aucune autre dépendance d’application, telles que vstest.console ou dotnet test nécessaire pour exécuter vos tests.

Microsoft.Testing.Platform est open source. Vous trouverez du code Microsoft.Testing.Platform dans le référentiel GitHub microsoft/testfx.

Frameworks de test pris en charge

Exécuter et déboguer des tests

Les projets de test Microsoft.Testing.Platform sont générés en tant qu’exécutables qui peuvent être exécutés (ou débogués) directement. Il n’existe aucune console ou commande supplémentaire exécutant des tests. L’application se ferme avec un code de sortie différent de zéro s’il existe une erreur, comme c’est généralement le cas avec la plupart des exécutables. Pour plus d’informations sur les codes de sortie connus, consultez codes de sortie Microsoft.Testing.Platform.

Important

Par défaut, Microsoft.Testing.Platform collecte les données de télémétrie. Pour plus d’informations et d’options sur la désactivation, consultez Télémétrie Microsoft.Testing.Platform.

La publication du projet de test à l’aide dotnet publish de l’application et l’exécution directe de l’application est un autre moyen d’exécuter vos tests. Par exemple, l’exécution du ./Contoso.MyTests.exe. Dans certains scénarios, il est également viable d’utiliser dotnet build pour produire l’exécutable, mais il peut y avoir des cas de périphérie à prendre en compte, comme AOT natif.

Utilisez dotnet run.

La dotnet run commande peut être utilisée pour générer et exécuter votre projet de test. C’est le plus simple, bien que parfois lent, moyen d’exécuter vos tests. L’utilisation de dotnet run est pratique lorsque vous modifiez et exécutez des tests localement, car elle garantit que le projet de test est reconstruit lorsque nécessaire. dotnet run recherche également automatiquement le projet dans le dossier actif.

dotnet run --project Contoso.MyTests

Pour plus d’informations sur dotnet run, consultez dotnet run.

Utilisez dotnet exec.

La commande dotnet exec ou dotnet est utilisée pour exécuter (ou lancer) un projet de test déjà généré, il s’agit d’une alternative à l’exécution directe de l’application. dotnet exec nécessite le chemin d’accès à la dll de projet de test générée.

dotnet exec Contoso.MyTests.dll

or

dotnet Contoso.MyTests.dll

Remarque

La fourniture du chemin d’accès à l’exécutable du projet de test (*.exe) entraîne une erreur :

Error:
  An assembly specified in the application dependencies manifest
  (Contoso.MyTests.deps.json) has already been found but with a different
  file extension:
    package: 'Contoso.MyTests', version: '1.0.0'
    path: 'Contoso.MyTests.dll'
    previously found assembly: 'S:\t\Contoso.MyTests\bin\Debug\net8.0\Contoso.MyTests.exe'

Pour plus d’informations sur dotnet exec, consultez dotnet exec.

Utilisez dotnet test.

Microsoft.Testing.Platform offre une couche de compatibilité avec vstest.console.exe et dotnet test, vous assurant que vous pouvez exécuter vos tests comme avant tout en activant un nouveau scénario d’exécution.

dotnet test Contoso.MyTests.dll

Options

La liste ci-dessous ne décrit que les options de la plateforme. Pour afficher les options spécifiques apportées par chaque extension, consultez la page de documentation de l’extension ou utilisez l’option --help.

  • --diagnostic

Permet d’afficher la page de journalisation des diagnostics. Le niveau de journalisation par défaut est Trace. Le fichier est écrit dans le répertoire de sortie au format de nom suivant. log_[MMddHHssfff].diag

  • --diagnostic-filelogger-synchronouswrite

Permet de forcer l’enregistreur d’événements de fichiers intégré à écrire des journaux de manière synchrone. Utile pour les scénarios où vous ne souhaitez perdre aucune entrée de journal (si le processus se bloque). Cela ralentit l’exécution de tests.

  • --diagnostic-output-directory

Le répertoire de sortie de la journalisation des diagnostics, s’il n’est pas spécifié, le fichier est généré dans le répertoire TestResults par défaut.

  • --diagnostic-output-fileprefix

Préfixe du nom de fichier journal. La valeur par défaut est "log_".

  • --diagnostic-verbosity

Permet de définir le niveau de verbosité lorsque le commutateur --diagnostic est utilisé. Les valeurs disponibles sont Trace, Debug, Information, Warning, Error ou Critical.

  • --help

Affiche une description de l’utilisation de la commande.

  • -ignore-exit-code

Permet à certains codes de sortie non nuls d’être ignorés et d’être retournés en tant que 0 à la place. Pour plus d’informations, consultez Ignorer des codes de sortie spécifiques.

  • --info

Affiche des informations avancées sur l’application de test .NET, telles que :

  • La plateforme.
  • L’environnement.
  • Chaque fournisseur de ligne de commande inscrit, tel que le sien, name, versiondescription et options.
  • Chaque outil inscrit, tel que le sien, command, name, version, description et tous les fournisseurs de ligne de commande.

Cette fonctionnalité est utilisée pour comprendre les extensions qui effectuent l’inscription de la même option de ligne de commande ou les modifications apportées aux options disponibles entre plusieurs versions d’une extension (ou la plateforme).

  • --list-tests

Répertoriez les tests disponibles. Les tests ne seront pas exécutés.

  • --minimum-expected-tests

Spécifie le nombre minimal de tests censés s’exécuter. Par défaut, au moins un test est censé s’exécuter.

  • --results-directory

Répertoire où les résultats de test doivent être placés. Si le répertoire spécifié n’existe pas, il est créé. La valeur par défaut est TestResults dans le répertoire qui contient l’application test.

Voir aussi