Microsoft는 MSTest와 Microsoft.Testing.Platform을 사용하여 UWP 및 WinUI 3 애플리케이션을 테스트하는 실용적인 가이드를 제공했으며, MSIX 형식으로 패키지된 애플리케이션, 비패키지 애플리케이션, AppContainer 내부에서 실행되는 애플리케이션 등 다양한 실행 모델에 걸쳐 테스트 수명 주기를 통합합니다. 이 자료는 수석 소프트웨어 엔지니어인 Amaury Levé가 작성했으며, UI 테스트 자체를 작성하는 것보다 테스트 호스트의 실행 방식을 결정하는 세부 사항에 중점을 둡니다.
실행 모델 선택
Microsoft는 패키징과 신뢰 수준을 구분합니다. 패키징은 MSIX ID와 AUMID 활성화 방식을 추가하는 반면, 신뢰 수준은 프로세스가 전체 권한으로 실행되는지 아니면 AppContainer 내부에서 실행되는지를 결정합니다. 이 자료에서는 패키지 ID, 패키지 활성화 계약 또는 설치된 애플리케이션 동작과의 일치가 필요하지 않은 경우 비패키지 WinUI 3 애플리케이션부터 시작할 것을 권장합니다. 반면 UWP는 본질적으로 패키징 및 AppContainer 환경과 연결되어 있습니다.
비패키지 애플리케이션에서 Microsoft.Testing.Platform은 apphost에서 직접 실행 경로를 사용하는 반면, 패키지 애플리케이션은 패키지 레이아웃을 등록하고 AUMID를 통해 활성화해야 합니다. AppContainer 내부에서 실행되도록 구성된 WinUI 3 애플리케이션은 컨트롤러, 취소, TRX 파일, HangDump 및 재시도용 통신 채널에 대한 접근 권한도 정밀하게 위임해야 합니다. Microsoft는 대신 ALL APPLICATION PACKAGES 권한을 부여하지 말라고 경고합니다.
MSTest 및 Microsoft.Testing.Platform 설정
Microsoft는 MSTest.Sdk 4.5를 설치하고 global.json 파일에서 Microsoft.Testing.Platform을 선택할 것을 권장합니다. 이렇게 하면 dotnet test 명령이 VSTest 대신 .NET 10의 기본 테스트 플랫폼을 사용합니다. MSTest.Sdk 4.5에는 MTP 2.5, 애플리케이션 모델용 사이드카 컨트롤러, 필요한 UWP 자산 및 패키지 애플리케이션 실행기가 포함되어 있습니다.
최신 UWP에서는 적절한 Windows 대상 프레임워크와 함께 UseUwp 및 PublishAot를 사용해야 합니다. 애플리케이션은 OnLaunched 내부에서 PackagedAppExtensions.GetTestApplicationArguments를 사용하여 생성된 도우미 MicrosoftTestingPlatformApplication.RunAsync에 활성화 인수를 전달해야 합니다. 기존 UWP 프로젝트는 현재 구조를 유지하고 MSBuild.Sdk.Extras와 함께 MSTest.Sdk를 가져온 다음 Developer PowerShell에서 InvokeTestingPlatform 대상(Target)을 통해 테스트를 실행합니다.
WinUI 3 호스트 및 UI 디스패처
이 자료에서는 자체 호스팅 WinUI 3 테스트 애플리케이션을 구축할 것을 제안합니다. 이 애플리케이션은 자체 창을 만들고 진입점을 보유한 뒤 동일한 프로세스 내부에서 MSTest를 실행합니다. 창을 활성화한 후 애플리케이션은 DispatcherQueue 객체를 UITestMethodAttribute.DispatcherQueue에 게시한 다음 RunAsync를 호출합니다. WinUI가 생성하는 진입점은 void 값을 반환하므로 Environment.ExitCode를 테스트 실행 결과로 설정해야 합니다. 이를 무시하면 빌드 시스템이나 CI에서 실패한 실행이 성공한 것으로 표시될 수 있습니다.
예제에서는 UITestMethod가 TestInitialize 및 TestCleanup을 포함한 전체 테스트를 WinUI 디스패처로 전달한다는 점을 설명합니다. 반면 STATestMethod는 STA 스레드를 제공하지만 자체적으로 WinUI 디스패처를 생성하지 않으므로 DispatcherQueue에 의존하는 UI 테스트에는 단독으로 충분하지 않습니다.
실제로 무엇이 달라지는가?
이 접근 방식의 핵심 가치는 UWP와 WinUI 3 사이 또는 패키지 실행과 비패키지 실행 사이를 전환할 때 배포 설정과 시작 경로만 변경하면서 MSTest와 동일한 테스트 수명 주기를 유지할 수 있다는 점입니다. 비패키지 WinUI 3에서는 WindowsPackageType을 None으로 설정하고 MSIX 도구를 비활성화합니다. 패키지 실행에서는 Package.appxmanifest 및 패키지 자산을 유지하며, Windows 10.0.19041.0 이상을 대상으로 하는 TFM과 Developer Mode 같은 사이드로드를 허용하는 정책이 필요합니다.
두 모델 모두 .NET 10에서 dotnet run 또는 dotnet test --project를 통해 실행할 수 있습니다. 반면 AppContainer 내부의 UWP 및 WinUI 3 테스트는 사용자 지정 MSBuild 대상과 권한 상승 없이 실행한 Developer PowerShell에서 실행합니다. Microsoft는 비패키지 애플리케이션에서 dotnet exec를 사용하지 말라고 경고합니다. 실행 경로에 dotnet.exe가 삽입되면 WinUI 리소스 로드 문제가 발생할 수 있기 때문입니다.
CI에서의 검증
패키지 테스트의 유효성을 확인하기에는 빌드 성공만으로 충분하지 않습니다. 실제 CI 에이전트 이미지, 패키지를 등록하는 사용자 컨텍스트, Developer Mode 또는 사이드로드 정책, 패키지가 선언하는 프레임워크를 점검해야 합니다. Windows App SDK 또는 UWP 패키지가 사전에 설치된 개발자 컴퓨터는 깨끗한 에이전트에서만 드러나는 격차를 숨길 수 있습니다. Windows App SDK 프레임워크에 의존하는 애플리케이션은 self-contained 형식으로 빌드하지 않는 한 일치하는 런타임 버전도 필요합니다. 이 경우에도 CI에서 사용할 것과 동일한 패키지 모델을 테스트해야 합니다.