Microsoft hat einen praktischen Leitfaden zum Testen von UWP- und WinUI-3-Anwendungen mit MSTest und der Microsoft.Testing.Platform veröffentlicht. Dabei wird der Lebenszyklus der Tests über verschiedene Ausführungsmodelle hinweg vereinheitlicht, darunter als MSIX verpackte Anwendungen, unverpackte Anwendungen und Anwendungen, die innerhalb eines AppContainers ausgeführt werden. Der Beitrag wurde von Amaury Levé, Principal Software Engineer, verfasst und konzentriert sich stärker auf die Details, die bestimmen, wie der Testhost ausgeführt wird, als auf das Schreiben der eigentlichen UI-Tests.
Auswahl des Ausführungsmodells
Microsoft unterscheidet zwischen Paketierung und Vertrauensstufe. Die Paketierung fügt eine MSIX-Identität und eine Aktivierungsmethode über die AUMID hinzu, während die Vertrauensstufe festlegt, ob der Prozess mit vollständigen Berechtigungen oder innerhalb eines AppContainers ausgeführt wird. Der Beitrag empfiehlt, mit einer unverpackten WinUI-3-Anwendung zu beginnen, wenn keine Paketidentität, keine verpackten Aktivierungsverträge und keine Übereinstimmung mit dem Verhalten einer installierten Anwendung erforderlich sind. UWP bleibt dagegen von seiner Natur her an die Paketierung und die AppContainer-Umgebung gebunden.
Bei unverpackten Anwendungen verwendet Microsoft.Testing.Platform einen direkten Ausführungspfad über apphost, während verpackte Anwendungen die Registrierung des Paketlayouts und die Aktivierung über die AUMID benötigen. WinUI-3-Anwendungen, die für die Ausführung innerhalb eines AppContainers konfiguriert sind, benötigen außerdem eine präzise Delegation des Zugriffs auf die Kommunikationskanäle für die Konsole, das Abbrechen, TRX-Dateien, HangDump und Wiederholungen. Microsoft warnt davor, stattdessen die Berechtigung ALL APPLICATION PACKAGES zu vergeben.
Einrichtung von MSTest und Microsoft.Testing.Platform
Microsoft empfiehlt, die Version MSTest.Sdk 4.5 zu installieren und Microsoft.Testing.Platform in der Datei global.json auszuwählen, damit der Befehl dotnet test die native Testplattform in .NET 10 anstelle von VSTest verwendet. MSTest.Sdk 4.5 umfasst die MTP 2.5, das seitliche Hostmodul für Anwendungsmodelle, die erforderlichen UWP-Assets und einen Launcher für verpackte Anwendungen.
Bei modernem UWP erfordert die Einrichtung die Verwendung von UseUwp und PublishAot zusammen mit einem geeigneten Windows-Ziel-Framework. Die Anwendung muss die Aktivierungsargumente aus OnLaunched an den generierten Helfer MicrosoftTestingPlatformApplication.RunAsync übergeben, und zwar mithilfe von PackagedAppExtensions.GetTestApplicationArguments. Herkömmliche UWP-Projekte behalten ihre bestehende Struktur bei und importieren MSTest.Sdk zusammen mit MSBuild.Sdk.Extras. Anschließend werden die Tests aus der Developer PowerShell über das Ziel InvokeTestingPlatform ausgeführt.
WinUI-3-Host und UI-Dispatcher
Der Beitrag schlägt vor, eine selbstgehostete WinUI-3-Testanwendung zu erstellen, sodass die Anwendung ihr Fenster erzeugt, den Einstiegspunkt besitzt und MSTest innerhalb desselben Prozesses ausführt. Nach der Aktivierung des Fensters veröffentlicht die Anwendung ein DispatcherQueue-Objekt in UITestMethodAttribute.DispatcherQueue und ruft anschließend RunAsync auf. Environment.ExitCode muss auf das Ergebnis der Testausführung gesetzt werden, da der von WinUI erzeugte Einstiegspunkt einen void-Wert zurückgibt. Wird dies ignoriert, kann eine fehlgeschlagene Ausführung gegenüber dem Build- oder CI-System als erfolgreich erscheinen.
Das Beispiel zeigt, dass UITestMethod den vollständigen Test, einschließlich TestInitialize und TestCleanup, an den WinUI-Dispatcher übergibt. STATestMethod stellt zwar einen STA-Thread bereit, erzeugt jedoch selbst keinen WinUI-Dispatcher und reicht daher allein für UI-Tests, die auf DispatcherQueue beruhen, nicht aus.
Was ändert sich praktisch?
Der wesentliche Wert dieses Ansatzes besteht darin, dass MSTest und der Testlebenszyklus beim Wechsel zwischen UWP und WinUI 3 oder zwischen verpackter und unverpackter Ausführung beibehalten werden können, während lediglich die Bereitstellungseinstellungen und der Startpfad geändert werden. Bei unverpacktem WinUI 3 wird WindowsPackageType auf None gesetzt und das MSIX-Tooling deaktiviert. Die verpackte Ausführung behält dagegen das Manifest Package.appxmanifest und die Paket-Assets bei und erfordert ein Windows-TFM ab 10.0.19041.0 sowie eine Richtlinie, die Sideloading erlaubt, beispielsweise den Developer Mode.
Beide Modelle können in .NET 10 über dotnet run oder dotnet test --project ausgeführt werden. UWP- und WinUI-3-Tests innerhalb eines AppContainers werden dagegen über das benutzerdefinierte MSBuild-Ziel und aus einer nicht erhöhten Developer PowerShell gestartet. Microsoft warnt davor, dotnet exec mit der unverpackten Anwendung zu verwenden, da die Einbindung von dotnet.exe in den Ausführungspfad Probleme beim Laden von WinUI-Ressourcen verursachen kann.
Überprüfung innerhalb von CI
Ein erfolgreicher Build reicht nicht aus, um die Gültigkeit verpackter Tests zu bestätigen. Das tatsächliche Image des CI-Agents, der Benutzerkontext, unter dem das Paket registriert wird, die Richtlinie für den Developer Mode oder Sideloading sowie die von dem Paket deklarierten Frameworks sollten überprüft werden. Ein Entwicklergerät, auf dem Windows App SDK oder UWP-Pakete bereits installiert sind, kann eine Lücke verbergen, die erst auf einem sauberen Agent sichtbar wird. Anwendungen, die auf dem Windows App SDK Framework basieren, benötigen außerdem die passende Runtime-Version, sofern sie nicht als self-contained erstellt wurden. Selbst in diesem Fall muss dasselbe Paketmodell getestet werden, das in CI verwendet wird.