MSTest 4.4를 사용하면 테스트 소스 생성과 Native AOT 및 트리밍을 통해, 애플리케이션이 프로덕션에서 사용할 수 있는 것과 동일한 배포 모델로 테스트 프로젝트를 실행할 수 있습니다. 이 아이디어는 일반적인 관리형 테스트 실행을 대체하려는 것이 아니라, 애플리케이션을 출시하기 전에 사전 컴파일 및 사용되지 않는 코드 제거와 관련된 문제를 발견하는 네이티브 경로를 추가하려는 것입니다.
Principal Software Engineer인 Amaury Levé에 따르면, MSTest.Sdk/4.4.0을 사용하고 net10.0을 대상으로 지정한 뒤 PublishAot=true를 설정하면 MSTest 소스 생성과 네이티브 실행 파일 경로가 활성화됩니다. MSTest.Sdk는 기본적으로 Microsoft Testing Platform, 즉 MTP를 사용합니다. 여전히 VSTest를 사용하는 프로젝트는 MTP로의 전환 지침을 검토해야 합니다. 명령줄 인자, CI 통합 및 지원되는 일부 .runsettings 항목이 다르기 때문입니다.
실제로 무엇이 달라지는가?
프로젝트를 구성한 뒤에는 애플리케이션이 대상으로 하는 것과 동일한 운영 체제 및 아키텍처에 맞춰 테스트를 게시해야 합니다. 원문에서는 linux-x64 식별자를 사용하는 예를 제시하며, 이를 win-x64 또는 osx-arm64와 같은 값으로 바꿀 수 있습니다. 게시한 후에는 생성된 실행 파일을 직접 실행하거나, Windows에서는 .exe 확장자를 사용해 실행합니다.
이 경로는 Assembly.GetTypes() 호출과 같은 어셈블리에 대한 포괄적인 리플렉션 검사 의존성을 줄이고, 생성된 특성과 델리게이트를 사용해 지원되는 테스트를 생성하고 호출합니다. 그러나 소스 생성이 Reflection이 전혀 없다는 뜻은 아닙니다. 기본 ReflectionFree 모드는 일부 예비 리플렉션 경로를 유지합니다. 호환성 문제를 조사할 때는 MSTestSourceGenMode=Rooting을 사용해 검색된 테스트 멤버를 유지하면서 리플렉션 실행을 계속할 수 있습니다.
확장 전에 제한적인 CI 경로 구축
실용적인 권장 사항은 일상적인 피드백을 위해 빠른 관리형 테스트 실행을 유지한 다음, 배포 경로와 직접 관련된 테스트 프로젝트 하나를 선택해 CI에 Native AOT 실험을 추가하는 것입니다. 두 경로는 다음 세 가지 측면에서 비교해야 합니다.
- 정확히 동일한 수의 테스트를 검색하는지 확인합니다.
- 테스트에서 동일한 결과를 얻는지 확인합니다.
- 게시 및 네이티브 실행 시간을 테스트 실행 시간과 분리해 기록합니다.
실험은 예약된 작업이나 릴리스 검증 단계에서 시작하고, 게시 및 추가 실행 비용을 감수할 만큼 제공되는 신호의 가치가 있을 때만 모든 병합 요청으로 확대하는 것이 좋습니다. 또한 직렬화, 의존성 주입, 구성 바인딩, Reflection에 의존하는 확장 기능 또는 Native AOT와의 호환성을 입증해야 하는 라이브러리처럼 배포에 민감한 경로를 테스트하는 프로젝트를 선택해야 합니다. 단순한 계산 테스트만 포함된 프로젝트는 애플리케이션의 실제 준비 상태에 대한 큰 증거를 제공하지 못합니다.
승인 게이트로 전환해야 하는 제약 사항
일부 테스트가 성공하고 프로세스가 성공적으로 종료되더라도 일부 클래스가 기록되지 않을 수 있습니다. 예를 들어 테스트 클래스가 [TestClass] 특성을 직접 선언하지 않고 상속만 하는 경우, 클래스가 접근 불가능하거나 파일 로컬이거나 정적이거나 공개되지 않았거나 추상적인 경우에 이런 일이 발생할 수 있습니다. 원문에 따르면 MSTEST0069 진단이 이러한 사례 중 하나를 발견하는 데 도움을 줍니다. 따라서 테스트 수의 일치는 무시할 수 있는 메모가 아니라 릴리스 조건이어야 합니다.
그 밖의 제약 사항으로는 일반 테스트 메서드 또는 ref, out, in 매개 변수를 사용하는 테스트 메서드가 있으며, [AssemblyFixtureProvider]를 통한 일부 정적 부분 패턴도 지원되지 않습니다. 또한 일부 MSTest SDK 통합, MTP 확장 기능 및 CI 보고서는 Native AOT 경로에서 사용할 수 없습니다. 반면 문서에 따르면 TRX 및 Code Coverage 지원은 계속 제공됩니다. 따라서 분석기 경고와 빌드 진단은 무시하는 경고가 아니라 전환 게이트로 다뤄야 합니다.
이 접근 방식이 중요한 이유
관리형 테스트와 Native AOT 경로는 서로 다른 두 가지 질문에 답합니다. 전자는 개발 주기를 단축하고, 후자는 테스트 자체가 애플리케이션에서 사용할 배포 모델 안에서 실행될 수 있는지 검증합니다. 이것이 최종 프로덕션 산출물에 대한 포괄적인 테스트와 같다는 뜻은 아닙니다. 설정, 운영 체제, 아키텍처, 외부 서비스 및 패키징이 달라질 수 있기 때문입니다. 그러나 테스트와 애플리케이션 사이에서 트리밍 및 사전 컴파일 모델이 달라지는 중요한 변수를 제거합니다.
성능 향상은 보장되지 않으며 주요 근거가 되어서도 안 됩니다. 소스 생성 덕분에 검색 및 시작 시간이 줄어들 수 있지만, 실행 시간, 프로세스 시작, 게시 및 남아 있는 Reflection이 전체 시간의 대부분을 차지할 수 있습니다. 여기서의 편집적 해석은 속도 향상이 제한적이더라도 실험의 핵심 가치는 테스트와 배포의 일치도를 높이는 것이라는 점입니다. 또한 이 접근 방식은 되돌릴 수 있습니다. 경로의 비용이 추가되는 신뢰보다 커지면 관리형 테스트 모음을 방해하지 않고 실행 빈도를 낮추거나 선택한 프로젝트를 변경하거나 실험을 중단할 수 있습니다.