Extension du Pont VSTest
Cette extension fournit une couche de compatibilité avec VSTest permettant aux infrastructures de test de continuer à prendre en charge une exécution en mode VSTest (vstest.console.exe, dotnet test courant, VSTest task sur AzDo, Explorateurs de tests de Visual Studio et Visual Studio Code...). Cette extension est fournie dans le cadre du package Microsoft.Testing.Extensions.VSTestBridge.
Compatibilité avec VSTest
L’objectif principal de cette extension est de faciliter et fluidifier l’expérience de mise à niveau pour les utilisateurs VSTest, en autorisant un mode double où la nouvelle plateforme est activée, mais également, en parallèle, un mode de compatibilité est proposé pour permettre aux workflows habituels de continuer à fonctionner.
Prise en charge de Runsettings
Cette extension vous permet de fournir un fichier VSTest .runsettings, mais toutes les options de ce fichier ne sont pas récupérées par la plateforme. Nous décrivons ci-dessous les paramètres (pris en charge et non pris en charge), les options de configuration et les alternatives aux options de configuration VSTest les plus utilisées.
Lorsqu’il est activé par le framework de test, vous pouvez utiliser --settings <SETTINGS_FILE> pour fournir le fichier .runsettings.
Élément RunConfiguration
L’élément RunConfiguration peut inclure les éléments suivants. Aucun de ces paramètres n’est respecté par Microsoft.Testing.Platform :
| Nœud | Description | Raison / Solution de contournement |
|---|---|---|
| MaxCpuCount | Ce paramètre contrôle le niveau de parallélisme au niveau du processus. Utilisez 0 pour activer le parallélisme maximal au niveau du processus. | Lorsque Microsoft.Testing.Platform est utilisé avec MSBuild, cette option est déchargée sur MSBuild. Lorsqu’un exécutable unique est exécuté, cette option n’a aucune signification pour Microsoft.Testing.Platform. |
| ResultsDirectory | Répertoire où les résultats des tests sont placés. Le chemin d’accès est relatif au répertoire qui contient le fichier .runsettings. | Utilisez l’option de ligne de commande --results-directory pour déterminer le répertoire dans lequel les résultats de tests seront 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. |
| TargetFrameworkVersion | Ce paramètre définit la version de l’infrastructure ou la famille d’infrastructure à utiliser pour exécuter des tests. | Cette option est ignorée. Les propriétés MSBuild <TargetFramework> ou <TargetFrameworks> déterminent la version cible de .Net Framework de l’application. Les tests sont hébergés dans l’application finale. |
| TargetPlatform | Ce paramètre définit l’architecture à utiliser pour exécuter des tests. | <RuntimeIdentifier> détermine l’architecture de l’application finale qui héberge les tests. |
| TreatTestAdapterErrorsAsWarnings | Supprime les erreurs de l’adaptateur de test pour devenir des avertissements. | Microsoft.Testing.Platform autorise l’exécution d’un seul type de tests à partir d’un assembly unique et l’échec de chargement de l’infrastructure de test ou d’autres parties de l’infrastructure devient une erreur impossible à ignorer, car cela signifie que certains tests n’ont pas pu être découverts ou exécutés. |
| TestAdaptersPaths | Un ou plusieurs chemins du répertoire où se trouvent les TestAdapters | Microsoft.Testing.Platform n’utilise pas le concept des adaptateurs de test et n’autorise pas le chargement dynamique d’extensions, sauf s’ils font partie de la build et sont inscrits dans Program.cs automatiquement via des cibles de build ou manuellement. |
| TestCaseFilter | Filtre pour limiter les tests qui s’exécutent. | Pour filtrer les tests, utilisez l’option de ligne de commande --filter. |
| TestSessionTimeout | Permet aux utilisateurs de mettre fin à une session de test lorsque celle-ci dépasse le délai spécifié. | Il n’existe aucune autre option. |
| DotnetHostPath | Spécifiez un chemin d’accès personnalisé à l’hôte dotnet utilisé pour exécuter l’hôte test. | Microsoft.Testing.Platform n’effectue aucune résolution supplémentaire de dotnet. Cela dépend entièrement de la façon dont dotnet se résout lui-même, ce qui peut être contrôlé par des variables d’environnement telles que DOTNET_HOST_PATH. |
| TreatNoTestsAsError | Quittez avec un code de sortie différent de zéro quand aucun test n’est détecté. | Microsoft.Testing.Platform va afficher une erreur par défaut lorsqu’aucun test n’est découvert ou exécuté dans une application test. Vous pouvez définir le nombre de tests que vous vous attendez à trouver dans l’assembly à l’aide du paramètre de ligne de commande --minimum-expected-tests, qui est défini par défaut sur 1. |
Élément DataCollectors
Microsoft.Testing.Platform n’utilise aucun collecteur de données. Au lieu de cela, il a le concept d’extensions in-process et out-of-process. Chaque extension est configurée par son fichier config respectif ou par le biais de la ligne de commande.
Plus important encore, les extensions hang, crashet couverture du code.
Élément LoggerRunSettings
Les enregistreurs d’événements dans Microsoft.Testing.Platform sont configurés au moyen de paramètres de ligne de commande ou de paramètres dans le code.
Prise en charge du filtre VSTest
Cette extension offre également la possibilité d’utiliser le mécanisme de filtrage VSTest pour découvrir ou exécuter uniquement les tests correspondant à l’expression de filtre. Pour plus d’informations, consultez la section Détails de l’option Filtre ou pour obtenir des détails propres à l’infrastructure, consultez la page Exécution de tests unitaires sélectifs.
Lorsqu’il est activé par le framework de test, vous pouvez utiliser --filter <FILTER_EXPRESSION>.
