문제는 빌드가 빨간색으로 표시되는 것 자체가 아니라, 그 원인이 새로운 회귀인지, 간헐적 테스트인지, 아니면 조사에 필요한 증거를 제거한 테스트 호스트의 중단인지 파악하는 데 있습니다. .NET Blog는 Microsoft.Testing.Platform(MTP)이 긴 로그 목록만 표시하는 대신 개발자, 검토자, 지속적 통합 도구에 더 유용한 테스트 보고서를 만드는 방법을 설명합니다.
이러한 방법은 GitHub Actions 또는 Azure DevOps를 사용하며 실패 정보가 풀 리퀘스트 내 의사 결정 지점에 도달하기를 원하는 팀을 대상으로 합니다. 또한 플랫폼은 한 번의 실행에서 둘 이상의 보고서 형식을 생성하고, 프로그램과 대시보드 및 개발 도구가 일관되게 사용할 수 있는 구조화된 출력을 제공합니다.
빌드 이력을 사용해 회귀와 간헐적 오류를 구분하세요
Azure DevOps는 이미 Tests 탭에 테스트 증거를 표시하지만, 보고기에 이력 기간을 전달하면 각 실패에 맥락이 추가됩니다. --report-azdo-flaky-history 14 옵션을 사용하면 플랫폼이 지난 14일 동안의 파이프라인 이력을 조회한 뒤, 간헐적으로 실패한 테스트와 유사한 이력이 없는 테스트를 구분합니다.
간헐적 테스트는 [flaky: failed 3/20 in last 14d]라는 레이블로 표시될 수 있으며, 이러한 기록이 없는 실패에는 [REGRESSION] 레이블이 붙습니다. 이를 통해 검토자는 적절한 경로에서 조사를 시작할 수 있습니다. 이력이 없는 실패는 잠재적 회귀로서 즉각적인 관심이 필요하고, 반복되는 실패는 알려진 이력에서 시작하면 됩니다.
팀이 이 동작을 지속적 통합에서 변경하려는 경우, --report-azdo-demote-known-flaky 옵션을 사용해 간헐적인 것으로 알려진 오류를 경고로 바꾸고 회귀는 오류로 유지할 수 있습니다. 그러나 문서에서는 결정이 명시적이어야 한다고 강조합니다. 이력을 검토자에게 방향을 제시하는 데만 사용할 것인지, 아니면 실패의 심각도 수준을 자동으로 변경할 것인지 결정해야 합니다. testfx 파이프라인에서는 이력 주석을 사용하면서 모든 실패 상태를 빌드를 차단하는 상태로 유지했습니다.
동일한 이력은 --report-azdo-slow-test-history를 통해 느린 테스트를 탐지하는 데에도 사용됩니다. 이 옵션은 조정 가능한 배수와 최소 실행 횟수 기준을 사용해 각 테스트를 이전 성능과 비교하므로, 단 한 번의 콜드 실행으로 부정확한 경고가 발생하지 않습니다.
테스트 호스트가 중단될 때 증거를 보존하세요
TRX 형식의 결과는 실행이 끝날 때 직렬화되었기 때문에 심각한 중단이 발생하면 보고서 전체가 손실될 수 있었습니다. 이제 결과는 생성되는 동안 디스크에 기록되며, 크래시 덤프 확장 기능과 함께 사용하면 호스트가 중단될 때 부분 보고서를 마무리할 수 있습니다.
dotnet test --report-trx --crashdump
그 결과 완료된 모든 테스트와 중단 당시 실행 중이던 테스트 목록을 포함하는 유효한 TRX 파일이 생성됩니다. 또한 확장 기능은 .crash.sequence.log 확장자를 가진 파일을 작성해 각 테스트의 시작과 종료를 기록하므로, 여러 테스트를 병렬로 실행할 때에도 시작되었지만 끝나지 않은 테스트를 파악하는 데 도움이 됩니다.
첨부 파일도 처리 대상에 포함됩니다. 이제 .NET Framework에서 경로가 Windows MAX_PATH 한도를 초과하더라도 크래시 덤프, 중단 주석, 테스트 확장 파일이 조용히 무시되지 않습니다. 첨부 파일을 복사할 수 없으면 TRX 파일 안에만 기록되는 대신 콘솔에 표시됩니다. 그 결과 불완전한 실행은 불완전한 상태로 명확히 표시되며, 누락된 증거를 숨기는 녹색 보고서처럼 보이지 않습니다.
소비 주체에 따라 보고서 형식을 선택하세요
한 번의 실행에서 별도의 변환 단계 없이 여러 형식을 활성화할 수 있습니다. TRX 형식은 .NET 도구에 적합하고, HTML은 직접 검토하는 데 적합하며, JUnit XML과 CTRF JSON은 대시보드와 기술을 넘나드는 자동화에 유용합니다. CTRF는 .NET 결과를 다른 언어의 결과와 집계하기 위한 공통 JSON 스키마를 제공합니다.
지속적 통합 시스템은 결과 보기에서 TRX와 JUnit 형식을 읽고, HTML과 CTRF는 다운로드하거나 대시보드에서 사용할 수 있는 파일로 표시합니다. Azure DevOps에서는 --report-azdo-upload-artifacts files 옵션을 사용해 결과 증거 파일을 자동으로 업로드할 수 있습니다. 또한 여러 실행 프레임워크를 대상으로 하는 프로젝트에서 결과가 충돌하지 않도록 --report-<format>-filename 옵션과 {asm}, {tfm} 같은 자리 표시자를 사용해 파일 이름을 지정해야 합니다.
출력을 안정적이고 자동화 가능하게 만드세요
--list-tests json 옵션은 검색된 테스트와 해당 소스 위치를 설명하는 스키마 버전이 지정된 문서를 제공합니다. 이는 버전마다 달라질 수 있는 콘솔 텍스트를 분석하는 대신 테스트 선택, 변경 영향 분석, 개발 환경 통합에 사용할 수 있는 안정적인 입력입니다.
MTP 출력은 에이전트 및 언어 모델 환경에 맞게 조정됩니다. 배너, ANSI 문자, 진행률 표시를 숨기고 기본적으로 실패한 테스트에 대해서만 stdout 및 stderr 출력을 표시합니다. 동작은 NO_COLOR와 --ansi 및 --progress 옵션으로 제어할 수 있습니다.
보고 정책을 고정하고 호환성을 확인하세요
문서에서는 하나의 테스트 프로젝트에서 MTP 2.3 이상을 시도한 다음, GitHub Actions에서는 --report-gh를, Azure DevOps에서는 --report-azdo를 활성화할 것을 권장합니다. 정책을 선택한 후에는 설정을 리포지토리 내부의 testconfig.json 파일에 저장하여 로컬 실행과 CI 실행에서 동일한 보고서를 생성하도록 합니다. 또한 Directory.Build.props를 사용해 모든 테스트 프로젝트에 통일된 설정을 적용하거나, AllMicrosoft 프로필을 사용해 안정적인 확장 기능 모음을 활성화할 수 있으며 JUnit과 CTRF는 선택 사항으로 유지됩니다.
MSTest.Sdk를 사용하지 않는 팀은 보고기 패키지 버전이 테스트 프레임워크가 대상으로 하는 MTP 버전과 일치하는지 확인해야 합니다. MTP 2.x 지원은 MSTest.TestAdapter 4.0.0, NUnit3TestAdapter 6.0.1, TUnit 1.7.16, YoloDev.Expecto.TestSdk 0.16.0 및 xunit.v3 4.0의 프리뷰 버전에 도달합니다. 또한 이 솔루션은 MTP 프로젝트와 VSTest 프로젝트를 혼합하는 것을 지원하지 않으므로, 리포지토리 수준에서 MTP 실행 참여를 설정해야 합니다.
Azure DevOps 이력 옵션에는 SYSTEM_ACCESSTOKEN: $(System.AccessToken) 토큰이 필요합니다. 토큰이 없으면 실행은 계속되지만 이력 주석은 건너뜁니다. 기존 파이프라인에서는 테스트 결과 게시 및 파일 게시 작업을 해당 MTP 옵션으로 대체할 수 있지만 코드 커버리지 게시 기능은 대체되지 않으므로 PublishCodeCoverageResults@2를 유지해야 합니다. 또한 직접 게시와 PublishTestResults@2를 함께 활성화해서는 안 됩니다. 동일한 빌드에 대해 별도의 테스트 실행 두 개가 생성되기 때문입니다.