Microsoft presentó una guía práctica para probar aplicaciones UWP y WinUI 3 mediante MSTest y Microsoft.Testing.Platform, unificando el ciclo de vida de las pruebas en distintos modelos de ejecución que incluyen aplicaciones empaquetadas en formato MSIX, aplicaciones no empaquetadas y aplicaciones que se ejecutan dentro de AppContainer. El material fue escrito por Amaury Levé, ingeniero principal de software, y se centra en los detalles que determinan cómo se ejecuta el host de pruebas más que en la escritura de las propias pruebas de interfaz.
Elección del modelo de ejecución
Microsoft distingue entre el empaquetado y el nivel de confianza. El empaquetado añade una identidad MSIX y un mecanismo de activación AUMID, mientras que el nivel de confianza determina si el proceso se ejecuta con privilegios completos o dentro de AppContainer. El material recomienda comenzar con una aplicación WinUI 3 no empaquetada cuando no se necesiten la identidad del paquete, los contratos de activación empaquetados o la coincidencia con el comportamiento de la aplicación instalada. UWP, por su parte, sigue estando vinculada por naturaleza al empaquetado y al entorno AppContainer.
En las aplicaciones no empaquetadas, Microsoft.Testing.Platform utiliza una ruta de ejecución directa desde apphost, mientras que las aplicaciones empaquetadas necesitan registrar el diseño del paquete y la activación mediante AUMID. Las aplicaciones WinUI 3 configuradas para ejecutarse dentro de AppContainer también requieren una delegación precisa del acceso a los canales de comunicación del controlador, la cancelación, los archivos TRX, HangDump y los reintentos; Microsoft advierte contra la concesión, en su lugar, del permiso ALL APPLICATION PACKAGES.
Configuración de MSTest y Microsoft.Testing.Platform
Microsoft recomienda instalar la versión MSTest.Sdk 4.5 y seleccionar Microsoft.Testing.Platform en el archivo global.json, para que el comando dotnet test utilice la plataforma de pruebas nativa de .NET 10 en lugar de VSTest. MSTest.Sdk 4.5 incluye MTP 2.5, el controlador lateral específico de los modelos de aplicaciones, los recursos necesarios para UWP y un ejecutor de aplicaciones empaquetadas.
En UWP moderno, la configuración requiere utilizar UseUwp y PublishAot con un marco de destino de Windows adecuado. La aplicación debe pasar los argumentos de activación al asistente generado MicrosoftTestingPlatformApplication.RunAsync desde OnLaunched, utilizando PackagedAppExtensions.GetTestApplicationArguments. Los proyectos UWP tradicionales conservan su estructura actual e importan MSTest.Sdk junto con MSBuild.Sdk.Extras; después, las pruebas se ejecutan desde Developer PowerShell mediante el destino InvokeTestingPlatform.
Host de WinUI 3 y despachador de la interfaz
El material propone construir una aplicación de pruebas de WinUI 3 autoalojada, de modo que la aplicación cree su ventana, sea propietaria del punto de entrada y ejecute MSTest dentro del mismo proceso. Después de activar la ventana, la aplicación publica un objeto DispatcherQueue en UITestMethodAttribute.DispatcherQueue y, a continuación, invoca RunAsync. Es necesario establecer Environment.ExitCode en el resultado de la ejecución de las pruebas, porque el punto de entrada que crea WinUI devuelve void, y omitirlo podría hacer que una ejecución fallida apareciera como exitosa ante el sistema de compilación o CI.
El ejemplo muestra que UITestMethod pasa la prueba completa, incluidos TestInitialize y TestCleanup, al despachador de WinUI. En cambio, STATestMethod proporciona un hilo STA, pero no crea por sí mismo un despachador de WinUI y, por tanto, no basta para las pruebas de interfaz que dependen de DispatcherQueue.
¿Qué cambia en la práctica?
El valor principal de este enfoque es la posibilidad de mantener MSTest y el mismo ciclo de vida de las pruebas al pasar de UWP a WinUI 3 o de la ejecución empaquetada a la no empaquetada, cambiando únicamente la configuración de publicación y la ruta de lanzamiento. En WinUI 3 no empaquetado, WindowsPackageType se establece en None y se deshabilita MSIX tooling. La ejecución empaquetada conserva el manifiesto Package.appxmanifest y los recursos del paquete, y requiere un TFM de Windows igual o posterior a 10.0.19041.0, además de una política que permita la instalación lateral, como Developer Mode.
Ambos modelos pueden ejecutarse mediante dotnet run o dotnet test --project en .NET 10, mientras que las pruebas de UWP y WinUI 3 dentro de AppContainer se ejecutan mediante el destino de MSBuild personalizado y desde Developer PowerShell sin privilegios elevados. Microsoft advierte contra el uso de dotnet exec con la aplicación no empaquetada, porque introducir dotnet.exe en la ruta de ejecución puede causar problemas al cargar recursos de WinUI.
Validación dentro de CI
El éxito de la compilación no basta para confirmar la validez de las pruebas empaquetadas. Es necesario revisar la imagen real del agente de CI, el contexto del usuario que registra el paquete, la política de Developer Mode o de instalación lateral y los marcos declarados por el paquete. Un equipo de desarrollo que ya tenga instalados Windows App SDK o paquetes UWP puede ocultar una brecha que solo aparezca en un agente limpio. Además, las aplicaciones que dependen del marco Windows App SDK necesitan la versión correspondiente del tiempo de ejecución, salvo que se compilen como self-contained; incluso en ese caso, se debe probar el mismo modelo de paquete que se utilizará en CI.