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.

Piliers microsoft.Testing.Platform

Cette nouvelle plateforme de test repose sur l’expérience de l’équipe .NET Developer Experience Testing et vise à relever les défis rencontrés depuis la publication de .NET Core en 2016. Bien qu’il existe un niveau élevé de compatibilité entre .NET Framework et .NET Core/.NET, certaines fonctionnalités clés telles que le plug-in-system et les nouveaux facteurs de forme possibles des compilations .NET ont rendu complexe l’évolution ou la prise en charge complète de la nouvelle fonctionnalité d’exécution avec l’architecture actuelle de la plateforme VSTest.

Les principaux facteurs moteurs de l’évolution de la nouvelle plateforme de test sont détaillés dans les éléments suivants :

  • Déterminisme : s’assurer que l’exécution des mêmes tests dans différents contextes (local, CI) produit le même résultat. Le nouveau runtime ne s’appuie pas sur la réflexion ou toute autre fonctionnalité de runtime .NET dynamique pour coordonner une exécution de test.

  • Transparence du runtime : le runtime de test n’interfère pas avec le code de l’infrastructure de test, il ne crée pas de contextes isolés tels AppDomain ou AssemblyLoadContext, et n’utilise pas de résolution d’assembly personnalisé ou de réflexion.

  • Inscription au moment de la compilation des extensions : les extensions, telles que les frameworks de test et les extensions in/out-of-process, sont inscrites pendant la compilation pour garantir le déterminisme et faciliter la détection des incohérences.

  • Dépendances zéro : le cœur de la plateforme est un assembly .NET unique, Microsoft.Testing.Platform.dllqui n’a aucune dépendance autre que les runtimes pris en charge.

  • Hostable : le runtime de test peut être hébergé dans n’importe quelle application .NET. Bien qu’une application console soit couramment utilisée pour exécuter des tests, vous pouvez créer une application de test dans n’importe quel type d’application .NET. Cela vous permet d’exécuter des tests dans des contextes spéciaux, tels que des appareils ou des navigateurs, où il peut y avoir des limitations.

  • Prise en charge de tous les facteurs de forme .NET : prendre en charge les facteurs de forme .NET actuels et futurs, y compris L’AOT natif.

  • Performant : trouver le bon équilibre entre les fonctionnalités et les points d’extension pour éviter de gonfler le runtime avec du code non fondamental. La nouvelle plateforme de test est conçue pour « orchestrer » une exécution de test, plutôt que de fournir des détails d’implémentation sur la façon de le faire.

  • Extensible suffisamment : la nouvelle plateforme repose sur des points d’extensibilité pour permettre une personnalisation maximale de l’exécution du runtime. Il vous permet de configurer l’hôte de processus de test, d’observer le processus de test et d’utiliser des informations à partir de l’infrastructure de test dans le processus hôte de test.

  • Déploiement de module unique : la fonctionnalité d’hébergement permet un modèle de déploiement de module unique, où un résultat de compilation unique peut être utilisé pour prendre en charge tous les points d’extensibilité, à la fois hors processus et in-process, sans avoir à expédier différents modules exécutables.

Frameworks de test pris en charge

  • MSTest. Dans MSTest, la prise en charge de Microsoft.Testing.Platform est effectuée via l’exécuteur MSTest.
  • NUnit. Dans NUnit, la prise en charge de Microsoft.Testing.Platform est effectuée par l’exécuteur NUnit.
  • xUnit.net : Dans xUnit.net, la prise en charge de Microsoft.Testing.Platformse fait par le runner xUnit.net.
  • TUnit : entièrement construit sur le Microsoft.Testing.Platform, pour plus d’informations, veuillez consulter la documentation TUnit

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.

Intégration de MSBuild

Le package NuGet Microsoft.Testing.Platform.MSBuild fournit diverses intégrations pour Microsoft.Testing.Platform avec MSBuild :

  • Prise en charge de dotnet test. Pour plus d'informations, consultez l'intégration des tests dotnet.
  • Support pour ProjectCapability requis par les Explorateurs de Tests Visual Studio et Visual Studio Code.
  • Génération automatique du point d’entrée (méthode Main).
  • Génération automatique du fichier de configuration.

Remarque

Cette intégration fonctionne de manière transitive (un projet qui fait référence à un autre projet faisant référence à ce package se comporte comme s’il référence le package) et peut être désactivé via la IsTestingPlatformApplication propriété MSBuild.

Voir aussi