Microsoft a publié un guide pratique pour tester les applications UWP et WinUI 3 au moyen de MSTest et de Microsoft.Testing.Platform, en uniformisant le cycle de vie des tests à travers différents modèles d’exécution, notamment les applications empaquetées au format MSIX, les applications non empaquetées et les applications exécutées dans AppContainer. Le document, rédigé par Amaury Levé, ingénieur logiciel principal, porte davantage sur les détails qui déterminent le mode d’exécution de l’hôte de test que sur l’écriture des tests d’interface eux-mêmes.
Choisir le modèle d’exécution
Microsoft distingue l’empaquetage du niveau de confiance. L’empaquetage ajoute une identité MSIX et un moyen d’activation AUMID, tandis que le niveau de confiance détermine si le processus s’exécute avec des privilèges complets ou dans AppContainer. Le document recommande de commencer par une application WinUI 3 non empaquetée lorsque l’identité du package, les contrats d’activation empaquetés ou la correspondance avec le comportement de l’application installée ne sont pas nécessaires. UWP reste, par nature, lié à l’empaquetage et à l’environnement AppContainer.
Pour les applications non empaquetées, Microsoft.Testing.Platform utilise un chemin d’exécution direct depuis apphost, tandis que les applications empaquetées nécessitent l’enregistrement de la disposition du package et l’activation via AUMID. Les applications WinUI 3 configurées pour s’exécuter dans AppContainer nécessitent également une délégation précise de l’accès aux canaux de communication utilisés par la console, l’annulation, les fichiers TRX, HangDump et les nouvelles tentatives ; Microsoft déconseille à la place d’accorder l’autorisation ALL APPLICATION PACKAGES.
Configurer MSTest et Microsoft.Testing.Platform
Microsoft recommande d’installer la version MSTest.Sdk 4.5 et de sélectionner Microsoft.Testing.Platform dans le fichier global.json, afin que la commande dotnet test utilise la plateforme de test native de .NET 10 plutôt que VSTest. MSTest.Sdk 4.5 inclut MTP 2.5, le module de console auxiliaire propre aux modèles d’application, les ressources UWP nécessaires et le lanceur d’applications empaquetées.
Dans l’UWP moderne, la configuration nécessite l’utilisation de UseUwp et de PublishAot avec un framework cible Windows approprié. L’application doit transmettre les arguments d’activation à l’assistant généré MicrosoftTestingPlatformApplication.RunAsync depuis OnLaunched, en utilisant PackagedAppExtensions.GetTestApplicationArguments. Les projets UWP traditionnels conservent leur structure actuelle et importent MSTest.Sdk aux côtés de MSBuild.Sdk.Extras, puis exécutent les tests depuis Developer PowerShell via la cible InvokeTestingPlatform.
Hôte WinUI 3 et répartiteur d’interface
Le document propose de construire une application de test WinUI 3 auto-hébergée, de sorte que l’application crée sa fenêtre, possède le point d’entrée, puis exécute MSTest dans le même processus. Après l’activation de la fenêtre, l’application publie l’objet DispatcherQueue dans UITestMethodAttribute.DispatcherQueue, puis appelle RunAsync. Il faut définir Environment.ExitCode sur le résultat de l’exécution des tests, car le point d’entrée créé par WinUI renvoie une valeur void, et le fait de l’ignorer peut faire apparaître une exécution échouée comme réussie pour le système de build ou le CI.
L’exemple montre que UITestMethod transmet le test complet, y compris TestInitialize et TestCleanup, au répartiteur WinUI. En revanche, STATestMethod fournit un thread STA, mais ne crée pas lui-même de répartiteur WinUI et ne suffit donc pas, à lui seul, pour les tests d’interface qui dépendent de DispatcherQueue.
Qu’est-ce qui change en pratique ?
La valeur principale de cette approche réside dans la possibilité de conserver MSTest et le même cycle de vie des tests lors du passage entre UWP et WinUI 3, ou entre une exécution empaquetée et non empaquetée, en ne modifiant que les paramètres de publication et le chemin de lancement. Dans WinUI 3 non empaqueté, WindowsPackageType est défini sur None et les outils MSIX sont désactivés. L’exécution empaquetée conserve le manifeste Package.appxmanifest et les ressources du package, et nécessite un TFM Windows en 10.0.19041.0 ou ultérieur ainsi qu’une stratégie autorisant l’installation latérale, telle que le Developer Mode.
Les deux modèles peuvent être exécutés avec dotnet run ou dotnet test --project dans .NET 10, tandis que les tests UWP et WinUI 3 dans AppContainer sont lancés via la cible MSBuild dédiée et depuis Developer PowerShell sans élévation de privilèges. Microsoft déconseille d’utiliser dotnet exec avec l’application non empaquetée, car l’introduction de dotnet.exe dans le chemin d’exécution peut provoquer des problèmes lors du chargement des ressources WinUI.
Validation dans le CI
La réussite de la compilation ne suffit pas à confirmer la validité des tests empaquetés. Il convient de vérifier l’image réelle de l’agent CI, le contexte utilisateur qui enregistre le package, la stratégie Developer Mode ou d’installation latérale, ainsi que les frameworks déclarés par le package. Un ordinateur de développement sur lequel Windows App SDK ou des packages UWP sont déjà installés peut masquer une lacune qui n’apparaîtra que sur un agent propre. Les applications dépendant du framework Windows App SDK nécessitent également la version correspondante du runtime, sauf si elles sont compilées au format self-contained, et même dans ce cas, il faut tester le même modèle de package que celui qui sera utilisé dans le CI.