Microsoft has provided a practical guide to testing UWP and WinUI 3 applications using MSTest and Microsoft.Testing.Platform, standardizing the test lifecycle across different execution models that include MSIX-packaged applications, unpackaged applications, and applications running inside AppContainer. The material was written by Amaury Levé, Principal Software Engineer, and focuses on the details that determine how the test host runs rather than on writing UI tests themselves.
Choosing the Execution Model
Microsoft distinguishes between packaging and trust level. Packaging adds an MSIX identity and an AUMID activation mechanism, while the trust level determines whether the process runs with full privileges or inside AppContainer. The material recommends starting with an unpackaged WinUI 3 application when package identity, packaged activation contracts, or matching the behavior of an installed application are not required. UWP, meanwhile, remains inherently tied to packaging and the AppContainer environment.
For unpackaged applications, Microsoft.Testing.Platform uses a direct execution path from apphost, while packaged applications require registering the package layout and activating it through AUMID. WinUI 3 applications configured to run inside AppContainer also require precise delegation of access to the communication channels for the controller, cancellation, TRX files, HangDump, and retry; Microsoft warns against granting ALL APPLICATION PACKAGES instead.
Configuring MSTest and Microsoft.Testing.Platform
Microsoft recommends installing MSTest.Sdk version 4.5 and selecting Microsoft.Testing.Platform in the global.json file so that the dotnet test command uses the native test platform in .NET 10 instead of VSTest. MSTest.Sdk 4.5 includes MTP 2.5, the sidecar controller for application models, the required UWP assets, and the packaged application runner.
In modern UWP, the setup requires using UseUwp and PublishAot with an appropriate Windows target framework. The application must pass the activation arguments to the generated helper MicrosoftTestingPlatformApplication.RunAsync from within OnLaunched, using PackagedAppExtensions.GetTestApplicationArguments. Traditional UWP projects retain their existing structure and import MSTest.Sdk alongside MSBuild.Sdk.Extras, then run the tests from Developer PowerShell through the InvokeTestingPlatform target.
WinUI 3 Host and UI Thread
The material proposes building a self-hosted WinUI 3 test application in which the application creates its window, owns the entry point, and then runs MSTest within the same process. After activating the window, the application publishes a DispatcherQueue object to UITestMethodAttribute.DispatcherQueue, then calls RunAsync. Environment.ExitCode must be set to the result of the test run because the entry point created by WinUI returns void, and ignoring this can cause a failed run to appear successful to the build system or CI.
The sample explains that UITestMethod passes the complete test, including TestInitialize and TestCleanup, to the WinUI thread. STATestMethod provides an STA thread but does not create a WinUI thread by itself, and therefore is not sufficient on its own for UI tests that depend on DispatcherQueue.
What Changes in Practice?
The main value of this approach is the ability to retain MSTest and the same test lifecycle when moving between UWP and WinUI 3 or between packaged and unpackaged execution, changing only the deployment settings and launch path. In unpackaged WinUI 3, WindowsPackageType is set to None and MSIX tooling is disabled. Packaged execution retains the Package.appxmanifest declaration and package assets, and requires a Windows TFM of 10.0.19041.0 or later and a policy that permits sideloading, such as Developer Mode.
Both models can be run through dotnet run or dotnet test --project in .NET 10, while UWP and WinUI 3 tests running inside AppContainer are launched through the custom MSBuild target and from an unelevated Developer PowerShell. Microsoft warns against using dotnet exec with the unpackaged application because introducing dotnet.exe into the execution path can cause problems loading WinUI resources.
Validation Inside CI
Successful builds are not enough to confirm the validity of packaged tests. The actual CI agent image, the user context that registers the package, the Developer Mode or sideloading policy, and the frameworks declared by the package should be checked. A developer machine with Windows App SDK or UWP packages preinstalled may hide a gap that appears only on a clean agent. Applications that depend on the Windows App SDK framework also require the matching runtime version unless they are built as self-contained, and even in that case the same package model that will be used in CI must be tested.