Testez les applications UWP et WinUI 3 avec MSTest et Microsoft. Testing.Platform

Utilisez Microsoft. Testing.Platform (MTP) pour exécuter des tests MSTest dans des applications UWP et WinUI 3. L’application agit en tant qu’hôte de test et possède son thread d’interface utilisateur et sa durée de vie de processus.

Important

La matrice complète de prise en charge des applications Windows décrite dans cet article est disponible avec MSTest 4.5 et MTP 2.5. Tant que les versions stables ne sont pas publiées, utilisez les packages de préversion 4.5 et 2.5 correspondants. Si vous gérez directement les paquets MTP, veillez à ce que les versions des paquets de la plateforme et de l’extension soient alignées.

Choisir un modèle d’application

MSTest.Sdk prend en charge les modèles d’application Windows suivants via MTP :

Modèle d’application Empaquetage et confiance Démarrage de l’hôte de test Exécutez la commande
UWP classique (uap10.0) AppContainer packagé Un sidecar de confiance totale inscrit le package et active l’application par ID de modèle utilisateur d’application (AUMID). MSBuild avec la cible InvokeTestingPlatform
UWP moderne (.NET 10 avec UseUwp) AppContainer empaqueté Un sidecar à confiance totale enregistre le package et active l’application à l’aide de l’AUMID. MSBuild avec la cible InvokeTestingPlatform
WinUI 3 empaqueté Confiance totale empaquetée Un sidecar de confiance totale inscrit le package et active l’application par AUMID. dotnet run ou dotnet test --project
WinUI 3 non empaqueté Aucune identité de package, confiance totale MTP démarre directement l’exécutable de l’application. dotnet run ou dotnet test --project
WinUI 3 packagedClassicApp avec TrustLevel="appContainer" AppContainer packagé Un sidecar de confiance totale active l’application et autorise son identificateur de sécurité de package exact (SID) sur les canaux de communication MTP. dotnet msbuild avec la cible InvokeTestingPlatform

L’empaquetage et le bac à sable sont des choix distincts. Une application de bureau WinUI 3 empaquetée a une identité de package, mais s’exécute en tant que processus de confiance totale par défaut. Une application UWP s’exécute toujours dans AppContainer. Une application WinUI 3 empaquetée s’exécute dans AppContainer uniquement lorsque son manifeste définit TrustLevel="appContainer".

Pour les anciennes versions MSTest ou MTP, conservez votre configuration VSTest existante pour les projets UWP. L’exécution MTP native pour les hôtes UWP et AppContainer nécessite MSTest 4.5 et MTP 2.5.

Comprendre le sidecar du modèle d’application MTP

Pour une application empaquetée, le processus initial de l’outil de test ne peut pas s’exécuter à l’intérieur du package. MSTest.Sdk démarre un contrôleur sidecar de confiance totale qui :

  • Prépare les arguments de ligne de commande et prend en charge l’annulation, les réessais, les rapports et la gestion du code de sortie.
  • Inscrit le package de sortie de build et active l’application manifeste exacte par AUMID.
  • Autorise uniquement le SID de package sélectionné lorsqu’un hôte AppContainer se connecte aux canaux nommés MTP.
  • Récupère les artefacts TRX, dump, diagnostic et nouvelle tentative à partir du stockage appartenant au package.

L’application de test héberge toujours MTP et MSTest dans son propre processus. L’exécution UWP ne nécessite pas Microsoft.NET.Test.Sdk, vstest.console, UwpTestHostRuntimeProvider ni l’environnement d’exécution de déploiement de Visual Studio.

Pour une application UWP windowsApp, Windows fournit une chaîne d’activation via LaunchActivatedEventArgs.Arguments au lieu des arguments de processus habituels. Appelez PackagedAppExtensions.GetTestApplicationArguments avant de créer le générateur MTP. L’extension empaquetée d’application restaure le tableau d’arguments d’origine et les métadonnées de connexion du contrôleur.

Pour un WinUI 3 packagedClassicApp, y compris celui qui s’exécute dans AppContainer, utilisez les arguments de processus normaux.

Respecter les conditions préalables

Utilisez les conditions préalables qui s’appliquent à votre projet :

  • Utilisez .NET SDK 10 ou version ultérieure pour la chaîne d’outils MSTest 4.5 et dotnet test --project.
  • Pour UWP, utilisez MSBuild de bureau à partir de Visual Studio avec la charge de travail plateforme Windows universelle et le KIT DE développement logiciel (SDK) Windows requis. Ces composants assurent une prise en charge uniquement au moment de la génération.
  • Pour WinUI 3, installez les outils de développement d’applications Windows et référencez une version SDK d'application Windows compatible.
  • Pour les applications de test empaquetées, activez Windows mode développeur ou configurez le chargement indépendant afin que Windows puisse inscrire une disposition de sortie de build non signée.
  • Pour les applications de test AppContainer, exécutez le contrôleur en tant qu’utilisateur non élevé.

Configurer des tests UWP

Configurer un projet UWP moderne

Utilisez MSTest.Sdk 4.5 ou version ultérieure, ciblez .NET 10 avec une version de plateforme Windows spécifiée, et définissez UseUwp sur true. Conservez vos paramètres UWP XAML, MSIX, architecture et AOT natifs existants.

Visual Studio active normalement UseUwpTools lors de la génération. MSTest.Sdk sélectionne le modèle d’application UWP lorsque UseUwpTools est true, ou lorsque true est UseUwp et que UseUwpTools n’est pas encore défini.

Si vous avez uniquement besoin de références UWP dans une application de test MTP non UWP, définissez UseUwpTools sur false. Le kit de développement logiciel (SDK) utilise ensuite le moteur d’exécution MTP direct, sauf si un autre modèle d’application empaquetée nécessite le sidecar.

Pour un projet complet, consultez l’exemple MTP UWP moderne.

Configurer un projet UWP classique

Conservez la forme de projet existante uap10.0 , la chaîne d’outils MSBuild de bureau et le Kit de développement logiciel (SDK) d’extension UWP. Importez MSTest.Sdk 4.5 ou version ultérieure et activez l’exécuteur MSTest et MTP. MSTest.Sdk fournit les ressources d’amorçage, d’adaptateur et d’exécution compatibles UAP.

Pour un projet complet, consultez l’exemple MTP UWP classique.

Exécuter des tests UWP

Ouvrez un Développeur PowerShell pour Visual Studio. Générez la solution pour une architecture concrète, puis appelez MTP :

msbuild UwpTests.sln /restore /p:Configuration=Release /p:Platform=x64
msbuild UwpTests.csproj /t:InvokeTestingPlatform /p:Configuration=Release /p:Platform=x64 /p:TestingPlatformCommandLineArguments="--report-trx"

La deuxième commande enregistre le package, active l’application à l’aide de l’AUMID, exécute des tests standard et des tests sur le thread d’interface utilisateur, copie les artefacts de résultat depuis le stockage du package et renvoie le code de sortie de l’exécution des tests.

Configurer des tests WinUI 3

Utilisez MSTest.Sdk 4.5 ou version ultérieure, défini UseWinUI sur trueet ciblez un framework cible Windows spécifique. Pour l’activation packagée, utilisez la version 10.0.19041.0 ou ultérieure de la plateforme Windows.

Héberger MTP à partir de l’application WinUI

Pour une application de test WinUI auto-hébergée, créez et activez la fenêtre de test dans OnLaunched, puis publiez sa file d’attente de répartiteur :

_window = new UnitTestAppWindow();
_window.Activate();
UITestMethodAttribute.DispatcherQueue = _window.DispatcherQueue;

Exécutez l’assistance MTP générée, affectez son résultat à Environment.ExitCode, fermez la fenêtre et appelez Exit:

Environment.ExitCode = await MicrosoftTestingPlatformApplication.RunAsync(
    Environment.GetCommandLineArgs()[1..]);

Utiliser UITestMethod pour les tests qui créent ou accèdent aux objets WinUI. Utilisez TestMethod pour les tests qui ne nécessitent pas le thread d’interface utilisateur.

Warning

N’ajoutez [assembly: WinUITestTarget(...)] pas à une application de test WinUI auto-hébergée. Cet attribut démarre une application WinUI pour un hôte de test distinct, mais l’application auto-hébergée a déjà appelé Application.Start.

Configurer une application non empaquetée

Réglez WindowsPackageType sur None. L’application n’a pas d’identité MSIX ou AppxManifest.xml, de sorte que MTP démarre son exécutable directement. N’ajoutez pas manuellement l’extension d’application empaquetée.

Le SDK d'application Windows injecte normalement son initialiseur bootstrap lorsque le projet remplit ces conditions :

  • WindowsPackageType a la valeur None.
  • OutputType est Exe ou WinExe.
  • WindowsAppSDKSelfContained n’est pas true.

Si un hôte qui n'est pas une application SDK d'application Windows charge votre bibliothèque de test, définissez-la WindowsAppSdkBootstrapInitializetrue dans la bibliothèque.

VSTest ne prend pas en charge les applications de test WinUI 3 non empaquetées, car son fournisseur WinUI nécessite un manifeste AppX.

Pour un projet complet, consultez l’exemple MTP WinUI non empaqueté.

Configurer une application de confiance totale empaquetée

Conservez la configuration WinUI empaquetée par défaut et son Package.appxmanifest. MSTest.Sdk référence et enregistre automatiquement Microsoft.Testing.Extensions.PackagedApp pour le projet empaqueté.

N’appelez pas non plus AddPackagedAppDeployment. Une exécution MTP ne peut inscrire qu’un seul lanceur d’hôtes de test. Défini EnableMicrosoftTestingExtensionsPackagedApp sur false uniquement lorsqu’un lanceur personnalisé possède une activation empaquetée.

Pour un projet complet, consultez l’exemple WinUI MTP empaqueté.

Configurer une application AppContainer

Dans le manifeste du package WinUI, configurez l’application en tant que packagedClassicApp et définissez TrustLevel="appContainer". MTP 2.5 autorise le SID de package exact sur le contrôleur et les canaux d’extension. Elle n’accorde pas ALL APPLICATION PACKAGES et ne nécessite pas d’exception de bouclage.

Exécutez le side-car non élevé. Utilisez la InvokeTestingPlatform cible pour que le sidecar puisse copier les résultats et les diagnostics du package LocalState vers le répertoire de résultats demandé.

Pour un projet complet, consultez l’exemple AppContainer WinUI MTP.

Exécuter des tests WinUI 3

Créez pour une architecture concrète. Pour une application à confiance totale empaquetée ou une application non empaquetée, exécutez :

dotnet build -p:Platform=x64
dotnet test --project . --no-build -p:Platform=x64

Vous pouvez également utiliser dotnet run --no-build -p:Platform=x64.

Pour une application WinUI AppContainer, utilisez la cible side-car et un répertoire de résultats absolus :

dotnet msbuild .\WinUITests.csproj -t:InvokeTestingPlatform -p:Platform=x64 "-p:TestingPlatformCommandLineArguments=--report-trx --results-directory C:\TestResults"

N’utilisez pas dotnet exec pour une application WinUI. WinUI résout les ressources PRI par rapport au chemin du processus.

Résoudre les problèmes d’installation

Symptôme Vérifier
L’application signale plusieurs appels à Application.Start. Supprimez l’attribut WinUITestTarget d’une application de test WinUI auto-hébergée.
L’exécution du test se termine, mais le processus reste ouvert. Fermez la fenêtre de test et appelez Exit une fois l’exécution MTP terminée.
Les tests ayant échoué retournent le code 0de sortie du processus. Affectez le résultat d’exécution MTP à Environment.ExitCode.
Une exécution WinUI non empaquetée signale l’absence de AppxManifest.xml. Vérifiez que le projet utilise MTP au lieu de VSTest.
Une exécution empaquetée ne peut pas inscrire ou activer l’application. Vérifiez le framework cible Windows, le mode développeur ou la stratégie de chargement d’applications en dehors du Microsoft Store, l’architecture et l’entrée d’exécutable dans le manifeste.
Un hôte AppContainer ne peut pas se connecter au contrôleur. Utilisez MSTest 4.5 et MTP 2.5 ou version ultérieure, puis exécutez le contrôleur sans élévation de privilèges.
Un rapport AppContainer n’est pas copié dans le répertoire demandé. Utilisez InvokeTestingPlatform et spécifiez un répertoire de résultats absolus.

Voir aussi

  • Dernière mise à jour :