dotnet test

아티클
03/27/2024

이 문서의 적용 대상: ✔️ .NET Core 3.1 SDK 이상 버전

이름

dotnet test - 단위 테스트를 실행하는 데 사용하는 .NET 테스트 드라이버입니다.

개요

dotnet test [<PROJECT> | <SOLUTION> | <DIRECTORY> | <DLL> | <EXE>]
    [--test-adapter-path <ADAPTER_PATH>]
    [-a|--arch <ARCHITECTURE>]
    [--blame]
    [--blame-crash]
    [--blame-crash-dump-type <DUMP_TYPE>]
    [--blame-crash-collect-always]
    [--blame-hang]
    [--blame-hang-dump-type <DUMP_TYPE>]
    [--blame-hang-timeout <TIMESPAN>]
    [-c|--configuration <CONFIGURATION>]
    [--collect <DATA_COLLECTOR_NAME>]
    [-d|--diag <LOG_FILE>]
    [-f|--framework <FRAMEWORK>]
    [-e|--environment <NAME="VALUE">]
    [--filter <EXPRESSION>]
    [--interactive]
    [-l|--logger <LOGGER>]
    [--no-build]
    [--nologo]
    [--no-restore]
    [-o|--output <OUTPUT_DIRECTORY>]
    [--os <OS>]
    [--results-directory <RESULTS_DIR>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [-s|--settings <SETTINGS_FILE>]
    [-t|--list-tests]
    [-v|--verbosity <LEVEL>]
    [<args>...]
    [[--] <RunSettings arguments>]

dotnet test -h|--help

설명

dotnet test 명령은 지정된 솔루션에서 단위 테스트를 실행하는 데 사용됩니다. dotnet test 명령은 솔루션을 빌드하고 솔루션의 각 테스트 프로젝트에 대해 테스트 호스트 애플리케이션을 실행합니다. 테스트 호스트는 테스트 프레임워크(예: MSTest, NUnit 또는 xUnit)를 사용하여 지정된 프로젝트에서 테스트를 실행하고 각 테스트의 성공 또는 실패를 보고합니다. 모든 테스트에 성공하면 Test Runner가 종료 코드로 0을 반환합니다. 테스트가 하나라도 실패하면 1을 반환합니다.

멀티 타기팅 프로젝트의 경우 각 대상 프레임워크에 대해 테스트가 실행됩니다. 테스트 호스트와 단위 테스트 프레임워크는 NuGet 패키지로 패키징되고 프로젝트에 대한 일반적인 종속성으로 복원됩니다. .NET 9 SDK부터 이러한 테스트는 기본적으로 병렬로 실행됩니다. 병렬 실행을 사용하지 않도록 설정하려면 MSBuild 속성을 false.로 설정합니다TestTfmsInParallel. 자세한 내용은 이 문서의 뒷부분에 있는 예제 명령줄과 병렬 로 테스트 실행을 참조하세요.

테스트 프로젝트는 다음 샘플 프로젝트 파일에서 볼 수 있듯이 일반적인 <PackageReference> 요소를 사용하여 테스트 러너를 지정합니다.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.9.0" />
    <PackageReference Include="xunit" Version="2.7.1" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.5.8" />
  </ItemGroup>

</Project>

여기서 Microsoft.NET.Test.Sdk는 테스트 호스트이고 xunit은 테스트 프레임워크입니다. xunit.runner.visualstudio는 xUnit 프레임워크가 테스트 호스트와 함께 작동할 수 있도록 하는 테스트 어댑터입니다.

암시적 복원

dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish 및 dotnet pack 등 복원이 필요한 모든 명령에 의해 암시적으로 실행되므로 dotnet restore를 실행할 필요가 없습니다. 암시적 복원을 사용하지 않으려면 --no-restore 옵션을 사용합니다.

dotnet restore 명령은 Azure DevOps Services의 연속 통합 빌드 또는 복원 발생 시점을 명시적으로 제어해야 하는 빌드 시스템과 같이 명시적으로 복원이 가능한 특정 시나리오에서 여전히 유용합니다.

NuGet 피드를 관리하는 방법에 대한 자세한 내용은 dotnet restore 설명서를 참조하세요.

워크로드 매니페스트 다운로드

이 명령을 실행하면 워크로드에 대한 광고 매니페스트의 비동기 백그라운드 다운로드가 시작됩니다. 이 명령이 완료될 때 다운로드가 계속 실행되면 다운로드가 중지됩니다. 자세한 내용은 광고 매니페스트를 참조하세요.

인수

PROJECT | SOLUTION | DIRECTORY | DLL | EXE
- 테스트 프로젝트의 경로입니다.
- 솔루션의 경로입니다.
- 프로젝트 또는 솔루션이 포함된 디렉터리의 경로입니다.
- 테스트 프로젝트 .dll 파일의 경로입니다.
- 테스트 프로젝트 .exe 파일의 경로입니다.
지정하지 않으면 DIRECTORY 인수를 사용하여 현재 디렉터리를 지정하는 것과 효과가 동일합니다.

옵션

Warning

옵션의 호환성이 손상되는 변경:

.NET 7부터: -a를 --test-adapter-path 대신 별칭 --arch로 전환합니다.
.NET 7부터: -r를 --results-directory 대신 별칭 --runtime로 전환합니다.

--test-adapter-path <ADAPTER_PATH>

추가 테스트 어댑터를 검색할 디렉터리의 경로입니다. 접미사가 .TestAdapter.dll인 .dll 파일만 검사됩니다. 지정하지 않으면 테스트 .dll의 디렉터리가 검색됩니다.

약식 -a는 7 이전의 .NET SDK 버전에서 사용할 수 있습니다.

--arch <ARCHITECTURE>

대상 아키텍처를 지정합니다. 이는 제공된 값이 기본 RID와 결합되는 RID(런타임 식별자)를 설정하는 약식 구문입니다. 예를 들어, win-x64 머신에서 --arch x86을 지정하면 RID가 win-x86으로 설정됩니다. 이 옵션을 사용하는 경우 -r|--runtime 옵션을 사용하지 마세요. .NET 6 미리 보기 7 이후 사용 가능합니다.

--blame

테스트를 원인 모드로 실행합니다. 이 옵션은 테스트 호스트의 크래시를 유발하는 문제가 있는 테스트를 격리하는 데 유용합니다. 크래시가 감지되면 크래시 전에 실행된 테스트의 순서를 캡처하는 시퀀스 파일이 TestResults/<Guid>/<Guid>_Sequence.xml에 만들어집니다.

이 옵션은 메모리 덤프를 만들지 않으며 테스트가 중단될 때 도움이 되지 않습니다.
--blame-crash(.NET 5.0 SDK부터 사용 가능)

테스트를 원인 모드를 실행하고 테스트 호스트가 예기치 않게 종료될 때 크래시 덤프를 수집합니다. 이 옵션은 사용되는 .NET 버전, 오류 유형, 운영 체제에 따라 달라집니다.

관리 코드의 예외에 대한 덤프는 .NET 5.0 이상 버전에서 자동으로 수집됩니다. testhost 또는 .NET 5.0에서 실행되고 충돌한 자식 프로세스에 대한 덤프가 생성됩니다. 네이티브 코드의 충돌에서는 덤프가 생성되지 않습니다. 이 옵션은 Windows, macOS, Linux에서 작동합니다.

네이티브 코드의 크래시 덤프 또는 .NET Core 3.1 이전 버전을 사용하는 경우의 크래시 덤프는 Procdump를 사용해야만 Windows에서 수집할 수 있습니다. procdump.exe 및 procdump64.exe를 포함하는 디렉터리가 PATH 또는 PROCDUMP_PATH 환경 변수에 있어야 합니다. 도구 다운로드. --blame을 의미합니다.

.NET 5.0 이상에서 실행되는 네이티브 애플리케이션에서 크래시 덤프를 수집하려면 VSTEST_DUMP_FORCEPROCDUMP 환경 변수를 1로 설정하여 Precdump 사용을 강제 적용할 수 있습니다.
--blame-crash-dump-type <DUMP_TYPE>(.NET 5.0 SDK부터 사용 가능)

수집할 크래시 덤프의 유형입니다. 지원되는 덤프 형식은 full(기본값) 및 mini입니다. --blame-crash을 의미합니다.
--blame-crash-collect-always(.NET 5.0 SDK부터 사용 가능)

예상된 테스트 호스트 종료와 예기치 않은 테스트 호스트 종료시 크래시 덤프를 수집합니다.
--blame-hang(.NET 5.0 SDK부터 사용 가능)

테스트를 원인 모드로 실행하고 테스트가 지정된 시간 제한을 초과하는 경우 중단 덤프를 수집합니다.
--blame-hang-dump-type <DUMP_TYPE>(.NET 5.0 SDK부터 사용 가능)

수집할 크래시 덤프의 유형입니다. full, mini 또는 none이어야 합니다. none을 지정하면 테스트 호스트가 시간 초과시 종료되지만 덤프를 수집하지 않습니다. --blame-hang을 의미합니다.
--blame-hang-timeout <TIMESPAN>(.NET 5.0 SDK부터 사용 가능)

중단 덤프가 트리거되고 테스트 호스트 프로세스와 모든 해당 자식 프로세스가 덤프되고 종료되는 테스트별 시간 제한입니다. 시간 제한 값은 다음 형식 중 하나로 지정됩니다.
- 1.5h, 1.5hour, 1.5hours
- 90m, 90min, 90minute, 90minutes
- 5400s, 5400sec, 5400second, 5400seconds
- 5400000ms, 5400000mil, 5400000millisecond, 5400000milliseconds
단위를 사용하지 않으면(예: 5400000) 값은 밀리초 단위로 간주합니다. 데이터 기반 테스트와 함께 사용되는 경우 시간 제한 동작은 사용되는 테스트 어댑터에 따라 다릅니다. xUnit의 경우 NUnit입니다. MSTest 2.2.4+에서는 모든 테스트 사례 후에 시간 제한이 갱신됩니다. 버전 2.2.4 이전 MSTest의 경우 모든 테스트 사례에 시간 제한이 사용됩니다. 이 옵션은 netcoreapp2.1 이상이 설치된 Windows, netcoreapp3.1 이상이 설치된 Linux 및 net5.0 이상이 설치된 macOS에서 지원됩니다. --blame 및 --blame-hang을 의미합니다.

-c|--configuration <CONFIGURATION>

빌드 구성을 정의합니다. 대부분의 프로젝트에 대한 기본값은 Debug이지만 프로젝트의 빌드 구성 설정을 재정의할 수 있습니다.

--collect <DATA_COLLECTOR_NAME>

테스트 실행에 대한 데이터 수집기를 사용하도록 설정합니다. 자세한 내용은 테스트 실행 모니터링 및 분석을 참조하세요.

예를 들어, --collect "Code Coverage" 옵션을 사용하여 코드 검사를 수집할 수 있습니다. 자세한 내용은 코드 검사 사용, 코드 검사 분석 사용자 지정 및 GitHub 문제 dotnet/docs#34479를 참조하세요.

코드 검사를 수집하려면 --collect "XPlat Code Coverage" 옵션을 사용하여 Coverlet을 사용할 수도 있습니다.
-d|--diag <LOG_FILE>

테스트 플랫폼에 대한 진단 모드를 사용하도록 설정하고 지정된 파일에, 그리고 옆의 파일에 진단 메시지를 기록합니다. 메시지를 기록하는 프로세스에 따라 생성되는 파일이 결정됩니다(예를 들어 테스트 호스트 로그의 경우 *.host_<date>.txt, 데이터 수집기 로그의 경우 *.datacollector_<date>.txt).
-e|--environment <NAME="VALUE">

환경 변수의 값을 설정합니다. 변수가 없으면 만들고, 있으면 재정의합니다. 이 옵션을 사용하면 테스트가 격리된 프로세스에서 실행됩니다. 옵션을 여러 번 지정하여 여러 변수를 제공할 수 있습니다.
-f|--framework <FRAMEWORK>

테스트를 실행할 대상 프레임워크의 TFM(대상 프레임워크 모니커)입니다. 대상 프레임워크도 프로젝트 파일에 지정되어야 합니다.
--filter <EXPRESSION>

지정된 식을 사용하여 현재 프로젝트의 테스트를 필터링합니다. 필터 식과 일치하는 테스트만 실행됩니다. 자세한 내용은 필터 옵션 세부 정보 섹션을 참조하세요. 선택적 단위 테스트 필터링을 사용하는 방법에 대한 자세한 내용 및 예제는 선택적 단위 테스트 실행을 참조하세요.

-?|-h|--help

명령을 사용하는 방법에 대한 설명을 출력합니다.

--interactive

명령이 중지되고 사용자 입력 또는 작업을 대기할 수 있도록 허용합니다. 예를 들어 인증을 완료합니다. .NET Core 3.0 SDK 이후 사용할 수 있습니다.

-l|--logger <LOGGER>

테스트 결과에 대한 로거를 지정하고 선택적으로 로거에 대한 스위치를 지정합니다. 여러 로거를 사용하도록 설정하려면 이 매개 변수를 여러 번 지정합니다. 자세한 내용은 이 문서 뒷부분에 나오는 테스트 결과 보고, 로거 스위치 및 예를 참조하세요.

명령줄 스위치를 로거에 전달하려면 다음을 수행합니다.
- 약어 형식이 아닌 스위치의 전체 이름을 사용합니다(예: v 대신 verbosity).
- 앞의 대시를 생략합니다.
- 각 스위치를 구분하는 공백을 세미콜론 ;로 바꿉니다.
- 스위치에 값이 있으면 해당 스위치와 해당 값 사이의 콜론 구분 기호를 등호 =로 바꿉니다.
예를 들어, -v:detailed --consoleLoggerParameters:ErrorsOnly는 verbosity=detailed;consoleLoggerParameters=ErrorsOnly가 됩니다.
--no-build

테스트 프로젝트를 실행하기 전에 빌드하지 않습니다. 또한 --no-restore 플래그를 암시적으로 설정합니다.
--nologo

Microsoft TestPlatform 배너를 표시하지 않고 테스트를 실행합니다. .NET Core 3.0 SDK 이후 사용할 수 있습니다.
--no-restore

명령을 실행할 때 암시적 복원을 실행하지 않습니다.
-o|--output <OUTPUT_DIRECTORY>

실행할 이진 파일을 찾을 디렉터리입니다. 지정하지 않으면 기본 경로는 ./bin/<configuration>/<framework>/입니다. TargetFrameworks 속성을 통해 여러 개의 대상 프레임워크가 지정된 프로젝트의 경우 이 옵션을 지정할 때 --framework도 정의해야 합니다. dotnet test는 항상 출력 디렉터리에서 테스트를 실행합니다. AppDomain.BaseDirectory를 사용하여 출력 디렉터리에서 테스트 자산을 사용할 수 있습니다.
- .NET 7.0.200 SDK 이상
  
  솔루션에서 이 명령을 실행할 때 --output 옵션을 지정하면 출력 경로의 의미 체계가 명확하지 않아 CLI에서 경고(오류 7.0.200)를 내보냅니다. 빌드된 모든 프로젝트의 모든 출력이 다중 대상 프로젝트와 호환되지 않는 지정된 디렉터리에 복사되고 서로 다른 버전의 직접 및 전이적 종속성이 있는 프로젝트로 복사되므로 --output 옵션이 허용되지 않습니다. 자세한 내용은 솔루션 수준 --output 옵션이 빌드 관련 명령에 더 이상 유효하지 않음을 참조하세요.

--os <OS>

대상 운영 체제(OS)를 지정합니다. 이는 제공된 값이 기본 RID와 결합되는 RID(런타임 식별자)를 설정하는 약식 구문입니다. 예를 들어, win-x64 머신에서 --os linux을 지정하면 RID가 linux-x64으로 설정됩니다. 이 옵션을 사용하는 경우 -r|--runtime 옵션을 사용하지 마세요. .NET 6부터 사용할 수 있습니다.

--results-directory <RESULTS_DIR>

테스트 결과가 배치될 디렉터리입니다. 지정한 디렉터리가 없으면 생성됩니다. 기본값은 프로젝트 파일이 포함된 디렉터리의 TestResults입니다.

약식 -r는 7 이전의 .NET SDK 버전에서 사용할 수 있습니다.
-r|--runtime <RUNTIME_IDENTIFIER>

테스트할 대상 런타임입니다.

.NET SDK 7부터 약식 -r을 사용할 수 있습니다.
-s|--settings <SETTINGS_FILE>

테스트 실행에 사용할 .runsettings 파일입니다. TargetPlatform 요소(x86|x64)는 dotnet test에 영향을 주지 않습니다. X86을 대상으로 하는 테스트를 실행하려면 x86 버전의 .NET Core를 설치합니다. 경로에 있는 dotnet.exe의 비트 수는 테스트를 실행하는 데 사용됩니다. 자세한 내용은 다음 리소스를 참조하세요.
- .runsettings 파일을 사용하여 단위 테스트를 구성합니다.
- 테스트 실행 구성
-t|--list-tests

테스트 실행 대신 검색한 테스트를 나열합니다.

-v|--verbosity <LEVEL>

명령의 세부 정보 표시 수준을 설정합니다. 허용되는 값은 q[uiet], m[inimal], n[ormal], d[etailed], diag[nostic]입니다. 기본값은 minimal입니다. 자세한 내용은 LoggerVerbosity를 참조하세요.

args

어댑터에 전달될 추가 인수를 지정합니다. 여러 개의 인수를 구분하려면 공백을 사용합니다.

가능한 인수 목록은 지정된 동작에 따라 다릅니다.
- 프로젝트, 솔루션 또는 디렉터리를 지정하거나 이 인수를 생략하면 호출이 msbuild로 전달됩니다. 이 경우 사용 가능한 인수는 dotnet msbuild 설명서에서 찾을 수 있습니다.
- .dll 또는 .exe를 지정하면 호출이 vstest로 전달됩니다. 이 경우 사용 가능한 인수는 dotnet vstest 설명서에서 찾을 수 있습니다.
RunSettings 인수

인라인 RunSettings는 명령줄에서 “-- ” 뒤에 마지막 인수로 전달됩니다(-- 다음에 공백 있음). 인라인 RunSettings는 [name]=[value] 쌍으로 지정됩니다. 공백은 여러 [name]=[value] 쌍을 구분하는 데 사용됩니다.

예: dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True

자세한 내용은 명령줄을 통해 RunSettings 인수 전달을 참조하세요.

예제

현재 디렉터리에 있는 프로젝트에서 테스트를 실행합니다.
```
dotnet test
```
test1 프로젝트에서 테스트를 실행합니다.
```
dotnet test ~/projects/test1/test1.csproj
```
test1.dll 어셈블리를 사용하여 테스트를 실행합니다.
```
dotnet test ~/projects/test1/bin/debug/test1.dll
```
현재 디렉터리의 프로젝트에서 테스트를 실행하고 trx 형식으로 테스트 결과 파일을 생성합니다.
```
dotnet test --logger trx
```
현재 디렉터리의 프로젝트에서 테스트를 실행하고 코드 검사 파일을 생성합니다(Coverlet 수집기 통합 설치 후).
```
dotnet test --collect:"XPlat Code Coverage"
```
현재 디렉터리의 프로젝트에서 테스트를 실행하고 코드 검사 파일을 생성합니다(Windows만 해당).
```
dotnet test --collect "Code Coverage"
```
현재 디렉터리의 프로젝트에서 테스트를 실행하고 콘솔에 세부 정보를 기록합니다.
```
dotnet test --logger "console;verbosity=detailed"
```
현재 디렉터리의 프로젝트에서 테스트를 실행하고 trx 로거를 사용하여 TestResults 폴더의 testResults.trx에 기록합니다.
```
dotnet test --logger "trx;logfilename=testResults.trx"
```
로그 파일 이름이 지정되므로 멀티 대상 프로젝트의 경우 각 대상 프레임워크마다 동일한 이름이 사용됩니다. 각 대상 프레임워크의 출력은 이전 대상 프레임워크의 출력을 덮어씁니다. 상대 경로는 해당 폴더에 상대적이기 때문에 파일은 테스트 프로젝트 폴더의 TestResults 폴더에 만들어집니다. 다음 예에서는 각 대상 프레임워크에 대해 별도의 파일을 생성하는 방법을 보여 줍니다.
현재 디렉터리의 프로젝트에서 테스트를 실행하고 trx 로거를 사용하여 각 대상 프레임워크에 고유한 파일 이름을 사용하여 TestResults 폴더의 파일에 기록합니다.
```
dotnet test --logger:"trx;LogFilePrefix=testResults"
```
현재 디렉터리의 프로젝트에서 테스트를 실행하고 HTML 로거를 사용하여 TestResults 폴더의 testResults.html에 기록합니다.
```
dotnet test --logger "html;logfilename=testResults.html"
```
현재 디렉터리의 프로젝트에서 테스트를 실행하고 테스트 호스트에서 크래시 발생 시 진행 중이던 테스트를 보고합니다.
```
dotnet test --blame
```
msbuild에 -bl(이진 파일 로그) 인수를 제공하여 test1 프로젝트에서 테스트를 실행합니다.
```
dotnet test ~/projects/test1/test1.csproj -bl
```
MSBuild DefineConstants 속성을 DEV로 설정하여 test1 프로젝트에서 테스트를 실행합니다.
```
dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"
```
MSBuild TestTfmsInParallel 속성을 false로 설정하여 test1 프로젝트에서 테스트를 실행합니다.
```
dotnet test ~/projects/test1/test1.csproj -p:TestTfmsInParallel=false
```

--filter <EXPRESSION>

<Expression>에 <property><operator><value>[|&<Expression>] 형식이 있습니다.

<property>은(는) Test Case의 특성입니다. 다음은 인기 있는 단위 테스트 프레임 워크에서 지원되는 속성입니다.

테스트 프레임워크	지원되는 속성
MSTest	FullyQualifiedName 이름 응용 프로그램 이름 우선 순위 TestCategory
xUnit	FullyQualifiedName DisplayName 범주
NUnit	FullyQualifiedName 이름 범주 우선 순위

<operator>은(는) 속성과 값 사이의 관계를 설명합니다.

연산자	기능
`=`	정확히 일치
`!=`	정확하게 일치하지 않음
`~`	포함
`!~`	포함하지 않음

<value>은(는) 문자열입니다. 모든 조회는 대/소문자를 구분합니다.

<operator>이(가) 없는 식은 FullyQualifiedName 속성의 contains(으)로 자동으로 간주됩니다(예를 들어 dotnet test --filter xyz과(와) dotnet test --filter FullyQualifiedName~xyz이(가) 동일).

식은 조건부 연산자와 조인할 수 있습니다.

연산자	기능
`\|`	OR
`&`	AND

조건부 연산자를 사용 하는 경우 식을 괄호로 묶을 수 있습니다(예: (Name~TestMethod1) | (Name~TestMethod2)).

선택적 단위 테스트 필터링을 사용하는 방법에 대한 자세한 내용 및 예제는 선택적 단위 테스트 실행을 참조하세요.

dotnet test

이름

개요

설명

암시적 복원

워크로드 매니페스트 다운로드

인수

옵션

예제

필터 옵션 세부 정보

참고 항목

피드백

추가 리소스