Microsoft представила практическое руководство по тестированию приложений UWP и WinUI 3 с помощью MSTest и Microsoft.Testing.Platform, унифицируя жизненный цикл тестов в различных моделях запуска, включая приложения, упакованные в формате MSIX, неупакованные приложения и приложения, работающие внутри AppContainer. Материал подготовил Amaury Levé, ведущий инженер-программист; основное внимание уделено деталям, определяющим способ запуска хоста тестирования, а не написанию самих тестов интерфейса.
Выбор модели запуска
Microsoft различает упаковку и уровень доверия. Упаковка добавляет удостоверение MSIX и способ активации AUMID, тогда как уровень доверия определяет, работает ли процесс с полными правами или внутри AppContainer. В материале рекомендуется начинать с неупакованного приложения WinUI 3, если не требуются удостоверение пакета, упакованные контракты активации или соответствие поведению установленного приложения. UWP по своей природе остаётся связанным с упаковкой и средой AppContainer.
Для неупакованных приложений Microsoft.Testing.Platform использует прямой путь запуска из apphost, тогда как упакованным приложениям требуется регистрация макета пакета и активация через AUMID. Приложения WinUI 3, настроенные для работы внутри AppContainer, также требуют точного предоставления доступа к каналам связи контроллера, отмены, файлов TRX, HangDump и повторного запуска; Microsoft предостерегает от предоставления разрешения ALL APPLICATION PACKAGES вместо этого.
Настройка MSTest и Microsoft.Testing.Platform
Microsoft рекомендует установить версию MSTest.Sdk 4.5 и выбрать Microsoft.Testing.Platform в файле global.json, чтобы команда dotnet test использовала встроенную платформу тестирования в .NET 10 вместо VSTest. MSTest.Sdk 4.5 включает MTP 2.5, боковой контроллер для моделей приложений, необходимые ресурсы UWP и средство запуска упакованных приложений.
В современном UWP настройка требует использования UseUwp и PublishAot с подходящей целевой платформой Windows. Приложение должно передавать аргументы активации сгенерированному помощнику MicrosoftTestingPlatformApplication.RunAsync из OnLaunched, используя PackagedAppExtensions.GetTestApplicationArguments. Традиционные проекты UWP сохраняют свою текущую структуру и импортируют MSTest.Sdk вместе с MSBuild.Sdk.Extras, после чего тесты запускаются из Developer PowerShell с помощью цели InvokeTestingPlatform.
Хост WinUI 3 и диспетчер интерфейса
Материал предлагает создать самодостаточное тестовое приложение WinUI 3, в котором приложение создаёт своё окно, владеет точкой входа и запускает MSTest в том же процессе. После активации окна приложение передаёт объект DispatcherQueue в UITestMethodAttribute.DispatcherQueue, а затем вызывает RunAsync. Необходимо установить Environment.ExitCode в результат выполнения тестов, поскольку точка входа, создаваемая WinUI, возвращает значение void; игнорирование этого может привести к тому, что неудачный запуск будет представлен системе сборки или CI как успешный.
В примере показано, что UITestMethod передаёт полный тест, включая TestInitialize и TestCleanup, диспетчеру WinUI. В то же время STATestMethod предоставляет поток STA, но сам по себе не создаёт диспетчер WinUI и поэтому недостаточен для тестов интерфейса, зависящих от DispatcherQueue.
Что практически меняется?
Главная ценность этого подхода заключается в возможности сохранять MSTest и тот же жизненный цикл тестов при переходе между UWP и WinUI 3 или между упакованным и неупакованным запуском, меняя только параметры публикации и путь запуска. В неупакованном WinUI 3 параметр WindowsPackageType устанавливается в None, а инструменты MSIX отключаются. При упакованном запуске сохраняются манифест Package.appxmanifest и ресурсы пакета; требуется TFM Windows версии 10.0.19041.0 или новее и политика, разрешающая боковую установку, например Developer Mode.
Обе модели можно запускать с помощью dotnet run или dotnet test --project в .NET 10, тогда как тесты UWP и WinUI 3 внутри AppContainer запускаются через специальную цель MSBuild из Developer PowerShell без повышенных привилегий. Microsoft предостерегает от использования dotnet exec с неупакованным приложением, поскольку включение dotnet.exe в путь запуска может вызвать проблемы при загрузке ресурсов WinUI.
Проверка в CI
Успешной сборки недостаточно, чтобы подтвердить работоспособность упакованных тестов. Следует проверить фактический образ агента CI, контекст пользователя, регистрирующего пакет, политику Developer Mode или боковой установки, а также платформы, объявленные пакетом. На компьютере разработчика, где уже установлены Windows App SDK или пакеты UWP, может быть скрыта проблема, проявляющаяся только на чистом агенте. Приложениям, зависящим от платформы Windows App SDK, требуется соответствующая версия среды выполнения, если только они не собраны в формате self-contained; даже в этом случае необходимо тестировать именно ту модель пакета, которая будет использоваться в CI.