Configuration du Kit de développement logiciel (SDK) MSTest

Cet article décrit les options de configuration avancées pour MSTest.Sdk. Pour une configuration de base et mise en route, consultez Mise en route avec MSTest.

Importante

Par défaut, MSTest.Sdk utilise l’exécuteur MSTest avec MTP, y compris avec le test dotnet. Cela nécessite la modification de vos appels CI et CLI locaux, et impacte également les entrées disponibles des .runsettings. Vous pouvez conserver les anciennes intégrations et outils en basculant vers VSTest.

MsTest.Sdk définit EnableMSTestRunner et TestingPlatformDotnetTestSupport a la valeur true par défaut. Pour plus d’informations sur dotnet test et ses différents modes, consultez Test avec dotnet test.

Bibliothèques d’assistance utilitaire de test

Si le project qui utilise MSTest.Sdk est destiné à être une bibliothèque d'assistance utilitaire de test et ne contient pas de tests exécutables, le project doit avoir <IsTestApplication>false</IsTestApplication>.

Sélectionner le coureur

Par défaut, le SDK MSTest s’appuie sur MTP, mais vous pouvez basculer vers VSTest en ajoutant la propriété <UseVSTest>true</UseVSTest>.

Étendre MTP

Vous pouvez personnaliser l’expérience MTP via un ensemble d’extensions de package NuGet. Pour simplifier et améliorer cette expérience, le SDK MSTest introduit deux fonctionnalités :

Profil Microsoft.Testing.Platform

Le concept de profiles vous permet de sélectionner l’ensemble par défaut de configurations et d’extensions qui seront appliquées à votre project de test.

Vous pouvez définir le profil en utilisant la propriété TestingExtensionsProfile sur l’un des trois profils suivants :

  • None - Aucune extension n’est activée.

  • Default - Active les extensions recommandées pour cette version de MSTest.SDK. Il s’agit de la valeur par défaut lorsque la propriété n’est pas explicitement définie.

    Active les extensions suivantes :

  • AllMicrosoft- Active les extensions Microsoft sélectionnées pour une utilisation prête à l’emploi étendue, y compris les extensions avec une licence restrictive. Les extensions expérimentales et api uniquement peuvent toujours nécessiter un opt-in explicite.

    Active toutes les extensions du profil Default, ainsi que les extensions suivantes :

    Dans msTest.Sdk versions 3.11.0 à 4.2.x, l’extension de rapport Azure DevOps est incluse uniquement dans AllMicrosoft.

Remarque

Les profils font référence aux packages Azure DevOps Report et GitHub Actions Report, mais la création de rapports reste désactivée lors de l’exécution. Passez --report-azdo pour activer la génération de rapports Azure DevOps. Pour activer les rapports GitHub Actions, exécutez les tests sur GitHub Actions et passez --report-gh.

Voici un exemple complet en tirant parti du profil None :

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <TestingExtensionsProfile>None</TestingExtensionsProfile>
    </PropertyGroup>

</Project>
Extension/Profil Aucun Par défaut AllMicrosoft
Couverture du code ✔️ ✔️
Vidage sur incident ✔️
Faux ✔️¹
Vidage sur blocage ✔️
Rechargement à chaud ✔️
Rapport HTML ✔️
rapport GitHub Actions ✔️³ ✔️³
réessayer ✔️
Trx ✔️ ✔️
rapport Azure DevOps ✔️³ ✔️²

¹ MSTest.Sdk 3.7.0+ ² MSTest.Sdk 3.11.0+ ¹ MSTest.Sdk 4.3.0+

Activer ou désactiver des extensions

Les extensions peuvent être activées et désactivées par les propriétés MSBuild avec le modèle Enable[NugetPackageNameWithoutDots].

Par exemple, pour activer l’extension d’image mémoire (package NuGet Microsoft.Testing.Extensions.CrashDump), utilisez l’ensemble de propriétés EnableMicrosoftTestingExtensionsCrashDump suivantes true:

<Project Sdk="MSTest.Sdk/4.1.0">

<PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <EnableMicrosoftTestingExtensionsCrashDump>true</EnableMicrosoftTestingExtensionsCrashDump>
</PropertyGroup>

</Project>

Pour obtenir la liste de toutes les extensions disponibles, consultez les fonctionnalités MTP.

Certaines extensions MTP restent facultatives et ne sont pas incluses dans les profils AllMicrosoft ou Default :

  • À compter de MSTest.Sdk 4.3, définissez <EnableMicrosoftTestingExtensionsJUnitReport>true</EnableMicrosoftTestingExtensionsJUnitReport>, puis passez --report-junit.
  • À compter de la préversion MSTest.Sdk 4.4, définissez <EnableMicrosoftTestingExtensionsCtrfReport>true</EnableMicrosoftTestingExtensionsCtrfReport>, puis passez --report-ctrf.
  • Pour référencer l’extension OpenTelemetry, définissez <EnableMicrosoftTestingExtensionsOpenTelemetry>true</EnableMicrosoftTestingExtensionsOpenTelemetry>. Étant donné que l’extension nécessite une configuration d’API, inscrivez-la dans votre point d’entrée personnalisé, comme décrit dans OpenTelemetry.

Ces extensions sont disponibles uniquement avec MTP.

Avertissement

Il est important de vérifier les conditions de licence de chaque extension car elles peuvent varier.

Les extensions activées et désactivées sont combinées aux extensions fournies par le profil d’extension que vous avez sélectionné.

Cette propriété peut être utilisée pour activer une extension supplémentaire en plus du profil implicite Default (comme dans l'exemple précédent CrashDumpExtension).

Vous pouvez également désactiver une extension provenant du profil sélectionné. Par exemple, désactivez l'extension MS Code Coverage en réglant <EnableMicrosoftTestingExtensionsCodeCoverage>false</EnableMicrosoftTestingExtensionsCodeCoverage> :

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <EnableMicrosoftTestingExtensionsCodeCoverage>false</EnableMicrosoftTestingExtensionsCodeCoverage>
    </PropertyGroup>

</Project>

Dans MSTest.Sdk 4.3.0 et versions ultérieures, le profil Default référence les packages Azure DevOps Report et GitHub Actions Report. Pour supprimer la référence du package, définissez <EnableMicrosoftTestingExtensionsAzureDevOpsReport>false</EnableMicrosoftTestingExtensionsAzureDevOpsReport> ou <EnableMicrosoftTestingExtensionsGitHubActionsReport>false</EnableMicrosoftTestingExtensionsGitHubActionsReport>. Si vous conservez les références de package, la création de rapports Azure DevOps ne démarre que lorsque vous transmettez --report-azdo. La génération de rapports GitHub Actions ne commence que lorsque vous exécutez les tests sur GitHub Actions et passez --report-gh.

Fonctionnalités

En dehors de la sélection du runner et des extensions spécifiques au runner, MSTest.Sdk fournit également des fonctionnalités supplémentaires pour simplifier et améliorer votre expérience de test.

Testez avec Aspire

Aspire est une pile d'opinion, prête pour le cloud, qui permet de construire des applications observables, prêtes pour la production et distribuées. Aspire est fourni par le biais d’une collection de packages NuGet qui gèrent des problèmes spécifiques liés au cloud natif. Pour plus d’informations, consultez la Aspire documentation.

Remarque

Cette fonctionnalité est disponible à partir de MSTest.Sdk 3.4.0.

En définissant la propriété EnableAspireTesting à true, vous pouvez apporter toutes les dépendances et directives using par défaut dont vous avez besoin pour les tests avec Aspire et MSTest.

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <EnableAspireTesting>true</EnableAspireTesting>
    </PropertyGroup>

</Project>

Testez avec Playwright

Playwright permet des tests de bout en bout fiables pour les web apps modernes. Pour obtenir plus d’informations, consultez la documentation Playwright officielle.

Remarque

Cette fonctionnalité est disponible à partir de MSTest.Sdk 3.4.0.

En définissant la propriété EnablePlaywright à true, vous pouvez apporter toutes les dépendances et directives using par défaut dont vous avez besoin pour les tests avec Playwright et MSTest.

<Project Sdk="MSTest.Sdk/4.1.0">

    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <EnablePlaywright>true</EnablePlaywright>
    </PropertyGroup>

</Project>

Migrer vers le SDK MSTest

Tenez compte des étapes suivantes qui sont requises pour migrer vers le kit de développement logiciel (SDK) MSTest.

Mettez à jour votre project

Lors de la migration d’un projet de test MSTest existant vers le KIT SDK MSTest, commencez par remplacer l’entrée Sdk="Microsoft.NET.Sdk" en haut de votre projet de test par Sdk="MSTest.Sdk"

- Sdk="Microsoft.NET.Sdk"
+ Sdk="MSTest.Sdk"

Ajoutez la version à votre global.json :

{
    "msbuild-sdks": {
        "MSTest.Sdk": "4.1.0"
    }
}

Vous pouvez ensuite commencer à simplifier votre project.

Supprimez les propriétés par défaut :

- <EnableMSTestRunner>true</EnableMSTestRunner>
- <OutputType>Exe</OutputType>
- <IsPackable>false</IsPackable>
- <IsTestProject>true</IsTestProject>

Supprimer les références de package par défaut :

- <PackageReference Include="MSTest"
- <PackageReference Include="MSTest.TestFramework"
- <PackageReference Include="MSTest.TestAdapter"
- <PackageReference Include="MSTest.Analyzers"
- <PackageReference Include="Microsoft.NET.Test.Sdk"

Enfin, en fonction du profil d'extensions que vous utilisez, vous pouvez également supprimer certains des packages Microsoft.Testing.Extensions.*.

Mettre à jour votre CI

Une fois que vous avez mis à jour vos projets, si vous utilisez MTP (par défaut) et si vous vous appuyez sur dotnet test l’exécution de vos tests, vous devez mettre à jour votre configuration CI. Pour plus d'informations et pour vous aider à comprendre tous les changements nécessaires, consultez intégration des tests dotnet.

Si vous utilisez le mode VSTest de dotnet test, voici un exemple de mise à jour lors de l'utilisation de la tâche DotNetCoreCLI dans Azure DevOps :

Le profil d’extension MSTest.Sdk par défaut fournit les packages Microsoft.Testing.Extensions.CodeCoverage et Microsoft.Testing.Extensions.TrxReport requis par les options ajoutées. Si vous sélectionnez le None profil, activez ou référencez les deux extensions avant d’utiliser les options.

\- task: DotNetCoreCLI@2
  inputs:
    command: 'test'
    projects: '**/**.sln'
-    arguments: '--configuration Release'
+    arguments: '--configuration Release -- --report-trx --results-directory $(Agent.TempDirectory) --coverage'

Générateur de code source par réflexion

Importante

Le comportement MSTest 4.4 suivant est disponible uniquement dans les versions préliminaires jusqu’à la publication de MSTest 4.4.0.

MSTest 4.3 a introduit le générateur de source de réflexion dans le package expérimental MSTest.SourceGeneration avec version indépendante. À compter de MSTest 4.4, le package est diplômé de l’état expérimental et utilise la version MSTest.

Les projets AOT natifs incluent automatiquement le générateur source. Pour un projet non-NativeAOT qui utilise MSTest.Sdk, activez cette option avec <EnableMSTestSourceGeneration>true</EnableMSTestSourceGeneration>. MSTest.Sdk aligne les versions de MSTest.TestAdapter, de MSTest.SourceGeneration et de MSTest.TestFramework via MSTestVersion.

Le Kit de développement logiciel (SDK) prend également en charge la génération de sources dans des bibliothèques de test et des projets réutilisables qui utilisent la gestion des packages centraux. Il fournit des hooks d’exécution correspondants MSTest.TestAdapter et génère les éléments requis PackageVersion .

.NET Standard ne prend pas en charge ces hooks d'exécution. Lorsque vous activez la génération de source pour une cible .NET Standard, le KIT de développement logiciel (SDK) signale cette erreur :

La génération de code source MSTest n’est pas prise en charge pour les frameworks cibles .NET Standard, car les points d’extension du runtime MSTest.TestAdapter requis ne sont pas disponibles.

Le générateur source découvre les tests au moment de la compilation. Lorsque le générateur est actif, les classes de test doivent déclarer [TestClass] directement au lieu de l’hériter. L’analyseur MSTEST0069 signale les classes qui s’appuient sur un [TestClass] hérité.

À partir de MSTest 4.3.2, MSTestSourceGenMode a pour valeur par défaut ReflectionFree pour les projets tronqués et Native AOT. Ce mode utilise les métadonnées générées et les invokeurs lorsqu’ils prennent en charge la structure du test. Sur les runtimes qui prennent en charge la réflexion, MSTest revient à la réflexion pour les entrées générées non prises en charge ou manquantes.

À compter de MSTest 4.4, la génération sans réflexion matérialise les métadonnées d’attribut héritées complètes, notamment AttributeUsage et AllowMultiple. Avec MTP, il peut contourner la découverte et la validation à l’exécution pour les méthodes synchrones simples [DataRow] et [TestMethod]. Les tests asynchrones, les attributs de méthode de test personnalisée, DynamicDatales implémentations personnalisées ITestDataSource et les formes de test ambiguës utilisent le chemin d’accès de secours. VSTest conserve également son chemin d’accès existant.

Le mode sans réflexion signale ces diagnostics :

id Forme de test non prise en charge
AOTSG0001 Classe de test statique
AOTSG0002 Ouvrir une classe de test générique, y compris une classe imbriquée dans un type générique
AOTSG0003 La classe qui a généré du code ne peut pas accéder, y compris une classe locale de fichier ou une imbrication privée ou privée protégée
AOTSG0004 Méthode de test générique
AOTSG0005 Méthode de test avec un paramètre ref, in ou out

Fonctionnalités expérimentales

Les fonctionnalités MSTest 4.3 suivantes sont expérimentales. Leurs API publiques sont susceptibles d’être modifiées et ne sont disponibles que via des diagnostics expérimentaux. Pour vous inscrire, reconnaissez l’ID de diagnostic correspondant.

Filtrage de test programmatique avec ITestFilter

Remarque

Introduit dans MSTest 4.3.0 (expérimental).

Le point d’extension expérimental ITestFilter , inscrit via [TestFilterProviderAttribute], vous permet de décider par programme si chaque test s’exécute, avant le chargement d’une classe de test. Cela est utile pour la logique de sélection personnalisée qui ne peut pas être exprimée avec des filtres de ligne de commande.

Implémentez ITestFilter.Filter(TestFilterContext) pour inspecter les métadonnées sans charger la classe de test :

public sealed class MyFilter : ITestFilter
{
    public TestFilterResult Filter(TestFilterContext context) =>
        context.DisplayName.Contains("Nightly", StringComparison.Ordinal)
            ? TestFilterResult.Run : TestFilterResult.Drop;
}

Retournez TestFilterResult.Run pour exécuter le test, Drop pour l’omettre sans enregistrer de résultat, ou Skip(reason) pour signaler le test comme ignoré. MSTest peut appeler une instance de filtre simultanément. Les implémentations doivent donc être thread-safe. Les filtres de ligne de commande et de l’Explorateur de tests s’exécutent avant ITestFilter, tandis que [Ignore] est évalué ensuite.

À compter de MSTest 4.4, .NET projets peuvent utiliser le formulaire [assembly: TestFilterProvider<MyFilter>]d’inscription générique de type sécurisé. Le compilateur impose ensuite que MyFilter implémente ITestFilter et dispose d’un constructeur public sans paramètre. L'attribut générique n'est pas disponible pour .NET Framework. Pour un projet multi-ciblé, sélectionnez le formulaire générique ou non générique avec un symbole de préprocesseur de framework cible.

#if NET
[assembly: TestFilterProvider<MyFilter>]
#else
[assembly: TestFilterProvider(typeof(MyFilter))]
#endif

À compter de MSTest 4.4, l’analyseur MSTEST0081 valide entièrement le formulaire d’inscription non générique. Pour la forme générique, il continue de signaler les types de filtres génériques et les assemblages qui enregistrent plus d’un fournisseur.

TestRun.Current et les tests planifiés

Remarque

Introduit dans MSTest 4.3.0 (expérimental).

L’API expérimentale TestRun.Current (à partir de RFC 014) expose des informations sur l’exécution actuelle, y compris l’ensemble des tests planifiés, afin que les extensions et les appareils puissent inspecter ce qui est planifié pour s’exécuter.

Limitations connues

Les kits SDK MSBuild fournis par NuGet (y compris MSTest.Sdk) ont prise en charge des outils délimités lorsqu'il s'agit de mettre à jour leur version, ce qui signifie que la mise à jour NuGet habituelle et l'interface utilisateur Visual Studio pour la gestion des packages NuGet ne fonctionne pas comme prévu. Vous devez mettre à jour manuellement la version dans le fichier global.json et dans le fichier project. (Cela s’applique même si vous utilisez Dependabot en raison de problèmes dependabot-core#12824 et dependabot-core#8615.)

Voir aussi

  • Last updated on