MSTest에서 실행 및 제어 테스트

MSTest는 플랫폼 또는 환경에 따라 병렬화, 스레딩 모델, 시간 제한, 재시도 및 조건부 실행을 포함하여 테스트 실행 방법을 제어하는 특성을 제공합니다.

스레딩 특성

스레딩 특성은 스레드 모델 테스트 메서드가 사용하는 것을 제어합니다. 이러한 특성은 특정 스레딩 요구 사항이 있는 COM 구성 요소, UI 요소 또는 코드를 테스트할 때 필수적입니다.

`STATestClassAttribute`

STATestClassAttribute는 모든 테스트 메서드(ClassInitialize 및 ClassCleanup 포함)를 단일 스레드 아파트(STA)에서 실행합니다. STA가 필요한 COM 개체를 테스트할 때 이 특성을 사용합니다.

[STATestClass]
public class ComInteropTests
{
    [TestMethod]
    public void TestComComponent()
    {
        // This test runs in an STA thread
        var comObject = new SomeComObject();
        // Test COM interactions
    }
}

비고

이 특성은 MSTest v3.6 이상에서 Windows에서만 지원됩니다.

`STATestMethodAttribute`

단일 STATestMethodAttribute 스레드 아파트에서 특정 테스트 메서드를 실행합니다. 클래스의 다른 테스트는 그렇지 않지만 STA가 필요한 개별 테스트에는 이 특성을 사용합니다.

[TestClass]
public class MixedThreadingTests
{
    [STATestMethod]
    public void TestRequiringSTA()
    {
        // This test runs in an STA thread
    }

    [TestMethod]
    public void RegularTest()
    {
        // This test uses default threading
    }
}

비고

이 특성은 MSTest v3.6 이상에서 Windows에서만 지원됩니다.

비동기 연속 작업에 대한 STA 컨텍스트 유지

MSTest 4.1부터 STATestMethodAttribute는 UseSTASynchronizationContext 속성을 포함하여 비동기 연속이 동일한 STA 스레드에서 실행되도록 합니다. 사용하도록 설정하면 이 특성은 연속 작업을 STA 스레드에 다시 게시하는 사용자 지정 SynchronizationContext 을 만듭니다. 이는 비동기 작업 전체에서 STA 스레딩이 필요한 UI 구성 요소를 테스트하는 데 필수적입니다.

[TestClass]
public class UIComponentTests
{
    [STATestMethod(UseSTASynchronizationContext = true)]
    public async Task TestAsyncUIOperation()
    {
        // Initial code runs on STA thread
        var control = new MyControl();
        
        await control.LoadDataAsync();
        
        // Continuation also runs on STA thread,
        // ensuring UI operations remain valid
        Assert.IsTrue(control.IsDataLoaded);
    }
}

팁 (조언)

비동기 작업을 수행하고 해당 연속 작업이 동일한 스레드에서 실행되도록 예상하는 Windows Forms 또는 WPF 구성 요소를 테스트할 때 사용합니다 UseSTASynchronizationContext = true .

`UITestMethodAttribute`

UITestMethod 속성은 UI 스레드에서 테스트 실행을 스케줄링합니다. 이 특성은 UI 스레드 액세스가 필요한 UWP 및 WinUI 애플리케이션을 테스트하기 위해 설계되었습니다.

[TestClass]
public class WinUITests
{
    [UITestMethod]
    public void TestUIComponent()
    {
        // This test runs on the UI thread
        var button = new Button();
        button.Content = "Click me";
        Assert.IsNotNull(button.Content);
    }
}

비고

이 특성에는 UWP 또는 WinUI 플랫폼에 적합한 MSTest 어댑터가 필요합니다. 자세한 내용은 플랫폼 지원 섹션을 참조하세요.

병렬화 특성

병렬 처리 특성은 테스트가 동시에 실행되는지 여부와 방법을 제어하여 테스트 실행 시간을 개선합니다.

병렬화 구성

MSTest는 기본적으로 각 테스트 어셈블리 내에서 순차적으로 테스트를 실행합니다. 다음 메커니즘 중 하나를 사용하여 어셈블리 내 병렬 처리를 명시적으로 사용하거나 사용하지 않도록 설정합니다.

메커니즘	병렬화 사용	병렬 처리 사용 안 함
원본 특성	`[assembly: Parallelize]`를 적용하고, 필요에 따라 범위와 작업자 수를 설정합니다.	어셈블리에 대한 병렬 처리를 비활성화하려면 `[assembly: DoNotParallelize]`을(를) 적용합니다. 어셈블리 병렬 처리를 사용하도록 설정한 후 해당 테스트만 옵트아웃하려면 클래스 또는 메서드에 적용 `[DoNotParallelize]` 합니다.
.runsettings	MSTest `Parallelize` 항목을 구성합니다.	`RunConfiguration.DisableParallelization`을 `true`로 설정합니다. 이 설정은 `[Parallelize]` 어셈블리에 특성이 있는 경우에도 병렬 처리를 강제로 해제합니다.
testconfig.json	`true`을 `mstest.parallelism.enabled`로 설정하고, 필요에 따라 `scope` 및 `workers`을 구성합니다.	`mstest.parallelism.enabled`을 `false`로 설정합니다.
MSBuild 속성	`MethodLevel`을(를) `ClassLevel` 또는 `MSTestParallelizeScope`로 설정하고, 필요에 따라 `MSTestParallelizeWorkers`도 설정합니다.	`MSTestParallelizeScope`을 `None`로 설정합니다. 이러한 속성은 해당 어셈블리 특성을 생성하므로 원본에서 특성을 선언하지 마세요.

`ParallelizeAttribute`

기본적으로 MSTest는 테스트를 순차적으로 실행합니다. ParallelizeAttribute 어셈블리 수준 특성을 사용하면 병렬 테스트 실행을 사용할 수 있습니다.

using Microsoft.VisualStudio.TestTools.UnitTesting;

[assembly: Parallelize(Workers = 0, Scope = ExecutionScope.MethodLevel)]

병렬 처리 범위

Scope	행동
`ClassLevel`	여러 테스트 클래스가 병렬로 실행되지만 클래스 내의 테스트는 순차적으로 실행됩니다.
`MethodLevel`	개별 테스트 메서드는 클래스에 관계없이 병렬로 실행할 수 있습니다.

작업자 스레드

이 속성은 Workers 병렬 실행을 위한 최대 스레드 수를 지정합니다.

0 (기본값): 컴퓨터의 논리 프로세서 수 사용
모든 양의 정수: 해당 특정 수의 스레드를 사용합니다.

// Parallelize at class level with 2 worker threads
[assembly: Parallelize(Workers = 2, Scope = ExecutionScope.ClassLevel)]

팁 (조언)

구성 메커니즘을 선택하려면 병렬 처리 구성을 참조하세요.

팁 (조언)

현재 많은 테스트에 순차적 실행이 필요한 경우에도 기본적으로 어셈블리 수준에서 병렬 처리를 사용하도록 설정합니다. 이 방법은 처음부터 병렬 실행을 지원하는 새 테스트를 작성하는 것이 좋습니다. MSTEST0001 분석기를 사용하여 어셈블리가 [assembly: Parallelize] 또는 [assembly: DoNotParallelize]를 사용하여 병렬 처리 의도를 명시적으로 선언하도록 확인합니다. 병렬 처리를 사용하도록 설정하면 각 테스트 클래스를 검토하여 동시 실행을 안전하게 지원하는지 여부를 확인합니다. 종종 몇 가지 클래스 또는 메서드 DoNotParallelize 만 제외하면 충분하므로 대부분의 테스트가 병렬로 실행되어 테스트 실행 속도가 훨씬 빨라집니다.

`DoNotParallelizeAttribute`

특정 DoNotParallelizeAttribute 어셈블리, 클래스 또는 메서드에 대한 병렬 실행을 방지합니다. 테스트가 동시에 안전하게 액세스할 수 없는 상태 또는 리소스를 공유하는 경우 이 특성을 사용합니다.

어셈블리 내 병렬 처리를 사용하도록 설정하면 MSTest는 각 테스트 원본(어셈블리)을 병렬화 가능하고 비교할 수 없는 테스트로 분할합니다. MSTest는 먼저 병렬 실행 가능한 집합을 실행한 다음, 해당 소스의 실행이 끝날 때 DoNotParallelize 집합을 테스트 한 번에 하나씩 실행합니다. 여러 테스트 원본을 포함하는 실행에서 각 원본에는 고유한 지연된 꼬리가 있습니다. 지연 테스트는 동일한 소스의 다른 테스트와 겹쳐 실행될 수 없으므로, 느린 지연 테스트는 일반적으로 해당 소스의 임계 경로를 대체로 자신의 실행 시간만큼 늘립니다.

MSTest는 병렬 처리 가능한 단계가 완료된 후에만 지연 테스트를 실행하므로 MSTest가 지연된 테스트를 실행하기 전에 취소되거나 중단된 실행이 종료될 수 있습니다. 여기에 설명된 실행 순서는 내부 구현 세부 정보이며 공개 계약이 아닙니다. 이후 버전의 MSTest에서 변경될 수 있습니다.

[assembly: Parallelize(Scope = ExecutionScope.MethodLevel)]

[TestClass]
public class ParallelTests
{
    [TestMethod]
    public void CanRunInParallel()
    {
        // This test can run with others
    }
}

[TestClass]
[DoNotParallelize]
public class SequentialTests
{
    [TestMethod]
    public void MustRunSequentially()
    {
        // This class's tests run sequentially
    }
}

[TestClass]
public class MixedTests
{
    [TestMethod]
    public void CanRunInParallel()
    {
        // This test can run with others
    }

    [TestMethod]
    [DoNotParallelize]
    public void MustBeIsolated()
    {
        // This specific test doesn't run in parallel
    }
}

비고

어셈블리 내 병렬 처리를 사용하도록 설정한 경우에만 필요합니다 DoNotParallelize . 병렬 처리를 사용하지 않도록 설정한 경우(기본값) DoNotParallelize 효과가 없습니다.

`ResourceLockAttribute`

동일한 명명된 리소스에 액세스하는 테스트만 직렬화하는 데 사용합니다 [ResourceLock] . 리소스 잠금과 달리 [DoNotParallelize]리소스 잠금은 관련 없는 리소스를 사용하는 테스트를 차단하지 않습니다. 기본 ReadWrite 모드는 배타적이지만 동일한 리소스에 대해 요청하는 ResourceAccessMode.Read 여러 테스트를 함께 실행할 수 있습니다.

private const string Database = "integration-database";

[TestMethod]
[ResourceLock(Database, Mode = ResourceAccessMode.Read)]
public void ReadsSharedSchema() { }

프로세스 전체 상태의 경우 WellKnownResources의 상수인 CurrentDirectory, EnvironmentVariables, Console를 사용합니다. 잠금 이름은 서수, 대/소문자 구분 같음 및 좌표 테스트를 하나의 테스트 원본 또는 어셈블리 내에서만 사용합니다. 이러한 테스트가 동일한 키를 사용하는 경우에도 별도의 어셈블리, 프로세스 또는 컴퓨터에서 테스트를 조정하지 않습니다.

잠금 범위는 구성된 병렬 처리 범위를 따릅니다.

MSTest ClassLevel는 클래스와 해당 메서드에 선언된 모든 잠금을 결합한 다음 전체 클래스 수명 주기에 대해 가장 강력한 모드를 유지합니다.
MethodLevel를 사용하면 MSTest는 해당 테스트의 초기화 및 정리를 포함해 각 테스트마다 잠금을 획득합니다.
병렬 처리를 사용하지 않도록 설정하면 리소스 잠금이 적용되지 않습니다.

테스트도 사용하는 [DoNotParallelize][DoNotParallelize] 경우 우선 순위가 적용되고 MSTest는 해당 리소스 잠금을 무시합니다. 경합 잠금을 기다리는 테스트는 작업자를 차지하므로 잠금 경합이 많을수록 처리량을 줄일 수 있습니다.

팁 (조언)

MSTest 4.4는 안정적인 잠금 키를 선언하고 공유 프로세스 상태를 보호하는 데 도움이 되도록 MSTEST0077 통해 MSTEST0073 병렬 안전 분석기를 추가합니다.

종속성 테스트

다른 테스트 후에 실행해야 하는 통합 또는 엔드 투 엔드 테스트에 사용합니다 [DependsOn] . 종속성은 방향성 순환 그래프를 형성하므로 독립적인 분기는 여전히 병렬로 실행될 수 있습니다.

[TestMethod]
public void CreateCart() { }

[TestMethod, DependsOn(nameof(CreateCart))]
public void PlaceOrder() { }

팬인에 여러 [DependsOn] 특성을 적용하거나 팬아웃을 위한 여러 테스트에 특성을 적용합니다. 동일한 클래스의 메서드, 다른 클래스의 모든 테스트 또는 다른 클래스의 메서드를 참조할 수 있습니다. 테스트 클래스에 적용 [DependsOn] 하여 해당 클래스의 모든 테스트에 종속성을 부여합니다. 종속성이 데이터 기반 테스트를 대상으로 하는 경우 MSTest는 모든 데이터 행을 기다립니다.

기본적으로 필수 조건이 실패하면 그에 종속된 항목은 건너뛰며, 이러한 건너뛰기는 전파됩니다. MSTest는 ProceedOnFailure를 에지별이 아니라 종속 테스트별로 평가합니다. 필수 구성 요소가 실패한 경우에도 종속 항목을 실행하려면 해당 테스트의 모든 [DependsOn] 선언에 ProceedOnFailure = true를 설정하세요. 기본값에 한 선언이 남아 있으면 MSTest가 종속 항목을 건너뜁니다. MSTest는 실행 전에 종속성 주기를 보고하고 주기의 테스트에 실패합니다. 종속성이 선택한 실행의 일부가 아닌 경우 MSTest는 누락된 에지를 경고하고 무시하므로 필터 및 단일 테스트 실행이 계속 작동합니다.

Microsoft. Testing.Platform에서는 다음에서 mstest.execution.dependencies 종속성을 선언할 수도 있습니다.testconfig.json

직선 시퀀스에 사용합니다 chains .
팬인, 팬아웃 및 proceedOnFailure에 nodes를 사용하세요.

{
  "mstest": { "execution": { "dependencies": {
    "chains": [["Contoso.Setup.CreateDatabase", "Contoso.Tests.ImportData"]],
    "nodes": [{ "test": "Contoso.Reports.*", "dependsOn": ["Contoso.Tests.ImportData"], "proceedOnFailure": true }]
  }}}
}

Namespace.Class.Method 이름으로 테스트 하나를 참조하거나, Namespace.Class.*로 클래스의 모든 테스트를 참조합니다. MSTest는 특성을 통해 선언된 종속성을 사용하여 구성 종속성을 병합합니다.

testconfig.json 형식은 Microsoft.Testing.Platform에서만 작동합니다. [DependsOn] 특성은 Microsoft.Testing.Platform과 VSTest 모두에서 작동합니다. 빌드 시간 유효성 검사를 위해 MSTEST0078 사용하도록 설정합니다.

팁 (조언)

단위 테스트의 경우 독립 테스트, 비품 또는 테스트별 설정을 선호합니다. 종속성은 테스트를 독립적으로 실행하기 어렵게 만들므로, 순서 자체가 시나리오의 일부인 테스트 스위트에서만 사용하세요.

시간 제한 속성

시간 제한 특성은 테스트가 무기한 실행되지 않도록 방지하고 성능 문제를 식별하는 데 도움이 됩니다.

`TimeoutAttribute`

테스트 TimeoutAttribute 또는 fixture 메서드를 실행할 수 있는 최대 시간(밀리초)을 지정합니다. 실행이 이 시간을 초과하면 테스트가 실패합니다.

[TestClass]
public class TimeoutTests
{
    [TestMethod]
    [Timeout(5000)] // 5 seconds
    public void TestWithTimeout()
    {
        // Test must complete within 5 seconds
    }
}

팁 (조언)

코드를 수정하지 않고 runettings() 또는 TestTimeout (timeout.test)를 통해 전역 테스트 시간 제한을 구성할 수 있습니다.

fixture 메서드에 시간 제한 적용

초기화 및 정리 메서드에 시간 제한을 적용할 수도 있습니다.

[TestClass]
public class FixtureTimeoutTests
{
    [ClassInitialize]
    [Timeout(10000)]
    public static void ClassInit(TestContext context)
    {
        // Must complete within 10 seconds
    }

    [TestInitialize]
    [Timeout(2000)]
    public void TestInit()
    {
        // Must complete within 2 seconds
    }
}

팁 (조언)

특성을 허용하는 [Timeout] 모든 fixture 메서드에는 동등한 전역 구성 설정이 있습니다. runsettings 또는 testconfig.json을 통해 전역적으로 시간 제한을 구성하고, TestInitializeTimeout, ClassInitializeTimeout, AssemblyInitializeTimeout 및 해당 정리 설정을 사용합니다.

비고

시간 제한이 정확하게 보장되는 것은 아닙니다. 지정된 시간이 지나면 테스트가 중단되지만 실제 취소 시간이 약간 더 오래 걸릴 수 있습니다.

상호 협력에 의한 취소

기본적으로 MSTest는 각 시간 제한 테스트 메서드를 별도의 작업 또는 스레드로 래핑합니다. 시간 제한에 도달하면 프레임워크는 테스트 관찰을 중지하지만 기본 작업은 백그라운드에서 계속 실행됩니다. 이 동작으로 인해 문제가 발생할 수 있습니다.

테스트 메서드는 시간 제한 후에도 리소스에 계속 액세스하고 상태를 변경합니다.
백그라운드 실행은 후속 테스트에 영향을 주는 경합 조건으로 이어질 수 있습니다.
시간이 지정된 각 메서드는 작업/스레드 래퍼에서 추가 오버헤드를 발생합니다.

MSTest 3.6부터 이 속성을 사용하여 CooperativeCancellation 이러한 문제를 방지합니다. 협업 모드에서는 MSTest가 테스트를 추가 작업으로 감싸지 않습니다. 대신 시간 제한에 도달하면 프레임워크는 취소 토큰을 신호로 표시합니다. 테스트 코드는 토큰을 정기적으로 확인하고 정상적으로 종료해야 합니다.

[TestClass]
public class CooperativeTimeoutTests
{
    [TestMethod]
    [Timeout(5000, CooperativeCancellation = true)]
    public async Task TestWithCooperativeCancellation(CancellationToken cancellationToken)
    {
        // Check the token periodically
        while (!cancellationToken.IsCancellationRequested)
        {
            await Task.Delay(100, cancellationToken);
            // Do work
        }
    }

    [TestMethod]
    [Timeout(5000, CooperativeCancellation = true)]
    public void SyncTestWithCooperativeCancellation(CancellationToken cancellationToken)
    {
        // Works with sync methods too
        for (int i = 0; i < 1000; i++)
        {
            cancellationToken.ThrowIfCancellationRequested();
            // Do work
        }
    }
}

협조적 취소의 이점:

성능 오버헤드가 낮아집니다(테스트당 추가 작업/스레드 래퍼 없음).
코드가 취소를 명시적으로 처리하기 때문에 리소스 정리가 더 깔끔합니다.
표준 .NET 취소 패턴에 맞춥니다.
테스트 코드와 관찰할 수 없는 백그라운드 실행 간의 경합 상태를 방지함으로써, 결정론적 동작을 유지하는 것입니다.

비고

협조적 취소를 수행하려면 테스트 코드에서 취소 토큰을 정기적으로 확인해야 합니다. 코드에서 토큰을 확인하지 않으면 시간 제한에 도달하면 테스트가 실제로 중지되지 않습니다.

팁 (조언)

각 특성에 개별적으로 설정하는 대신 runsettings 또는 testconfig.json 통해 모든 시간 제한 특성에 대해 전역적으로 협조적 취소를 사용하도록 설정할 수 있습니다.

팁 (조언)

관련 분석기:

MSTEST0045 - 시간 제한 특성에 대해 협조적 취소를 사용하는 것이 좋습니다.

특성 다시 시도

실패한 테스트를 자동으로 다시 실행하는 재시도 속성은 불안정한 테스트를 처리하는 데 도움이 됩니다.

`RetryAttribute`

MSTest 3.8에 도입된 RetryAttribute은 실패하거나 시간이 초과된 테스트 메서드를 자동으로 다시 시도합니다. 최대 재시도 횟수, 재시도 간 지연 시간, 및 백오프 전략을 구성할 수 있습니다.

[TestClass]
public class RetryTests
{
    [TestMethod]
    [Retry(3)] // Retry up to 3 times if the test fails
    public void FlakeyNetworkTest()
    {
        // Test that might occasionally fail due to network issues
    }

    [TestMethod]
    [Retry(3, MillisecondsDelayBetweenRetries = 1000, BackoffType = DelayBackoffType.Exponential)]
    public void TestWithExponentialBackoff()
    {
        // Retries with increasing delays: 1s, 2s, 4s
    }

    [TestMethod]
    [Retry(5, MillisecondsDelayBetweenRetries = 500, BackoffType = DelayBackoffType.Constant)]
    public void TestWithConstantDelay()
    {
        // Retries with constant 500ms delay between attempts
    }
}

구성 옵션

재산	Description	Default
`MaxRetryAttempts`	최대 재시도 횟수(읽기 전용, 생성자를 통해 설정)	필수
`MillisecondsDelayBetweenRetries`	재시도 사이의 기본 지연(ms)	0
`BackoffType`	`Constant` 또는 `Exponential` 지연	`Constant`

비고

테스트 메서드에는 하나 RetryAttribute 만 있을 수 있습니다. RetryAttribute로 표시되지 않은 메서드에서는 TestMethod을(를) 사용할 수 없습니다.

비고

MSTest 4.3 RetryAttribute 부터 테스트 클래스 수준에서도 적용할 수 있습니다. 테스트 클래스에 적용하면 클래스의 모든 테스트 메서드에 적용됩니다. 메서드에 있는 A RetryAttribute는 해당 메서드를 포함하는 클래스에 있는 A보다 우선 적용됩니다.

MSTest 4.4부터 Microsoft.Testing.Platform은 터미널 출력에 각 재시도 시도를 표시하고, 실행 요약에서 불안정한 테스트와 재시도된 테스트를 식별합니다. CTRF 보고서에는 재시도 세부 정보가 포함됩니다. TRX 및 JUnit 보고서는 테스트당 하나의 최종 결과를 계속 포함하며 대체된 시도는 프로세스 종료 코드에 영향을 주지 않습니다.

팁 (조언)

관련 분석기:

MSTEST0043: 테스트 메서드에 RetryAttribute을(를) 사용하는 것이 좋습니다.

사용자 지정 다시 시도 구현

MSTest 3.8부터는 RetryBaseAttribute을(를) 상속하여 사용자 지정 재시도 로직을 만들 수 있습니다.

Important

RetryBaseAttribute.ExecuteAsync API와 해당 RetryContext 및 RetryResult 형식은 실험적입니다. 이를 사용하면 MSTESTEXP 진단이 표시되며, API를 사용하기 전에 이를 확인해야 합니다.

MSTest 4.4 RetryResult.AllResults 부터는 추가된 순서대로 모든 시도의 결과 배열을 노출합니다. MTP는 이전 시도를 대체된 것으로 보고하고 VSTest는 최종 결과만 받습니다. MSTest는 시도에 실패하거나 시간이 초과된 결과가 포함된 경우에만 다시 시도합니다. 결정적이지 않은 결과 자체는 재시도 시퀀스를 중지합니다.

프로세스 수준 --retry-failed-tests 및 MSTest 재시도 특성은 서로 다른 수준에서 적용됩니다. 각 프로세스 수준 시도가 특성의 전체 재시도 시퀀스를 실행할 수 있으므로 해당 효과는 곱합니다.

public class CustomRetryAttribute : RetryBaseAttribute
{
    private readonly int _maxRetries;

    public CustomRetryAttribute(int maxRetries)
    {
        _maxRetries = maxRetries;
    }

    // Implement abstract members
    // Add custom logic for retry conditions
}

조건부 실행 특성

조건부 실행 특성은 운영 체제 또는 CI 환경과 같은 특정 조건에 따라 테스트가 실행되는지 여부를 제어합니다.

`ConditionBaseAttribute`

ConditionBaseAttribute 조건부 실행을 위한 추상 기본 클래스입니다. MSTest는 몇 가지 기본 제공 구현을 제공합니다.

비고

MSTest ConditionBaseAttribute 3.8에서 도입되었습니다.

비고

기본적으로 조건 특성은 상속되지 않습니다. 기본 클래스에 적용해도 파생 클래스에는 영향을 주지 않습니다. 사용자 지정 조건 특성은 AttributeUsage을 재정의하여 이러한 동작을 변경할 수 있지만, 기본 제공 조건 특성과의 일관성을 유지하기 위해 이를 권장하지 않습니다.

팁 (조언)

관련 분석기:

MSTEST0041 - 테스트 클래스와 함께 조건 기반 특성을 사용하는 것이 좋습니다.

`OSConditionAttribute`

OSConditionAttribute 운영 체제에 따라 테스트를 실행하거나 건너뜁니다. 플래그 열거형을 OperatingSystems 사용하여 적용되는 운영 체제를 지정합니다.

비고

MSTest OSConditionAttribute 3.8에서 도입되었습니다.

[TestClass]
public class OSSpecificTests
{
    [TestMethod]
    [OSCondition(OperatingSystems.Windows)]
    public void WindowsOnlyTest()
    {
        // Runs only on Windows
    }

    [TestMethod]
    [OSCondition(OperatingSystems.Linux | OperatingSystems.OSX)]
    public void UnixLikeOnlyTest()
    {
        // Runs on Linux or macOS
    }

    [TestMethod]
    [OSCondition(ConditionMode.Exclude, OperatingSystems.Windows)]
    public void SkipOnWindowsTest()
    {
        // Runs on any OS except Windows
    }
}

지원되는 운영 체제

OS	Description
`Windows`	Microsoft Windows
`Linux`	Linux 배포
`OSX`	macOS
`FreeBSD`	FreeBSD

운영 체제를 비트 OR 연산자(|)와 결합합니다.

팁 (조언)

관련 분석기:

MSTEST0061 - 런타임 검사 대신 OSCondition 특성을 사용하는 것이 권장됩니다.

`CIConditionAttribute`

연속 통합 환경에서 실행되고 있는 경우인지에 따라 CIConditionAttribute가 테스트를 실행하거나 건너뜁니다.

비고

MSTest CIConditionAttribute 3.10에서 도입되었습니다.

[TestClass]
public class CIAwareTests
{
    [TestMethod]
    [CICondition(ConditionMode.Include)]
    public void CIOnlyTest()
    {
        // Runs only in CI environments
    }

    [TestMethod]
    [CICondition(ConditionMode.Exclude)]
    public void LocalDevelopmentOnlyTest()
    {
        // Skipped in CI, runs during local development
    }
}

`MemberConditionAttribute`

MSTest 4.3에 도입된 이 메서드는 MemberConditionAttribute하나 이상의 정적 bool 멤버 값에 따라 테스트 클래스 또는 테스트 메서드를 실행하거나 건너뜁니다. 각 멤버는 선언 형식과 이름으로 참조되며, public static이어야 하고, bool을(를) 반환해야 하며, (메서드의 경우) 매개 변수가 없어야 합니다. 여러 멤버를 지정하면 논리적 AND와 결합됩니다. 조건을 반전하는 데 사용합니다 ConditionMode .

public static class TestConditions
{
    public static bool IsFeatureEnabled => true;
}

[TestClass]
public class FeatureTests
{
    [TestMethod]
    [MemberCondition(typeof(TestConditions), nameof(TestConditions.IsFeatureEnabled))]
    public void RunsWhenFeatureEnabled()
    {
    }

    [TestMethod]
    [MemberCondition(ConditionMode.Exclude, typeof(TestConditions), nameof(TestConditions.IsFeatureEnabled))]
    public void SkippedWhenFeatureEnabled()
    {
    }
}

팁 (조언)

관련 분석기: MSTEST0070 - [MemberCondition] 인수가 유효해야 합니다.

`ArchitectureConditionAttribute`

MSTest 4.3에 도입된 이 테스트는 ArchitectureConditionAttribute프로세스 아키텍처에 따라 테스트를 실행하거나 건너뜁니다. 플래그 열거형을 TestArchitectures 사용하여 적용되는 아키텍처를 지정합니다.

[TestClass]
public class ArchitectureTests
{
    [TestMethod]
    [ArchitectureCondition(TestArchitectures.X64)]
    public void RunsOnX64()
    {
    }

    [TestMethod]
    [ArchitectureCondition(ConditionMode.Exclude, TestArchitectures.X86)]
    public void SkippedOnX86()
    {
    }
}

`ExecutableConditionAttribute`

MSTest 4.3에 도입된 이 ExecutableConditionAttribute기능은 외부 도구를 사용할 수 있는지 여부에 따라 테스트를 실행하거나 건너뜁니다. 이 테스트는 지정된 실행 파일을 확인할 수 있는 경우에만 실행됩니다. 필요에 따라 도구를 검색할 때 사용되는 인수를 전달할 수 있습니다.

[TestClass]
public class ToolTests
{
    [TestMethod]
    [ExecutableCondition("git")]
    public void RunsWhenGitIsAvailable()
    {
    }

    [TestMethod]
    [ExecutableCondition("docker", "--version")]
    public void RunsWhenDockerResponds()
    {
    }
}

`IgnoreAttribute`

IgnoreAttribute 무조건 테스트 클래스 또는 메서드를 건너뜁니다. 필요에 따라 무시 이유를 제공합니다.

팁 (조언)

관련 분석기: MSTEST0015 - 테스트 메서드는 무시해서는 안 됩니다. 이 분석기를 사용하여 영구적으로 무시되는 테스트를 검색합니다.

[TestClass]
public class IgnoreExamples
{
    [TestMethod]
    [Ignore]
    public void TemporarilyDisabled()
    {
        // This test is skipped
    }

    [TestMethod]
    [Ignore("Waiting for bug #123 to be fixed")]
    public void DisabledWithReason()
    {
        // This test is skipped with a documented reason
    }
}

[TestClass]
[Ignore("Entire class needs refactoring")]
public class IgnoredTestClass
{
    [TestMethod]
    public void Test1() { }  // Skipped

    [TestMethod]
    public void Test2() { }  // Skipped
}

작업 항목에 연결

알려진 문제로 인해 테스트를 무시하는 경우 추적을 위해 WorkItemAttribute 또는 GitHubWorkItemAttribute를 사용하십시오.

[TestClass]
public class TrackedIgnoreExamples
{
    [TestMethod]
    [Ignore("Waiting for fix")]
    [WorkItem(12345)]
    public void TestWithWorkItem()
    {
        // Linked to work item 12345
    }

    [TestMethod]
    [Ignore("Known issue")]
    [GitHubWorkItem("https://github.com/owner/repo/issues/42")]
    public void TestWithGitHubIssue()
    {
        // Linked to GitHub issue #42
    }
}

모범 사례

병렬 처리를 현명하게 사용: 독립 테스트에 병렬 처리를 사용하도록 설정하지만 상태를 공유하는 테스트에 사용합니다 DoNotParallelize .
적절한 시간 제한 설정: 정상적인 실행을 허용하지만 중단된 테스트를 catch하는 시간 제한을 선택합니다. 느린 CI 환경을 고려합니다.
협조적 취소 선호: 협조적 취소를 사용하여 추가 작업 래퍼의 오버헤드를 방지하고 시간 초과 테스트의 백그라운드 실행을 방지합니다. MSTEST0045 분석기를 사용하도록 설정하여 이 방법을 적용합니다.
무시된 테스트 문서: 테스트를 무시할 때 항상 이유 및 작업 항목 참조를 제공합니다.
재시도를 절제하여 사용: 재시도에 의존하지 말고, 불안정한 테스트의 근본 원인을 해결하십시오.
OS 관련 코드 적절하게 테스트: 해당되는 경우에만 플랫폼별 테스트를 실행하는 데 사용합니다 OSCondition .

참고하십시오

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-10-01

MSTest에서 실행 및 제어 테스트

스레딩 특성

STATestClassAttribute

STATestMethodAttribute

비동기 연속 작업에 대한 STA 컨텍스트 유지

UITestMethodAttribute

병렬화 특성

병렬화 구성

ParallelizeAttribute

병렬 처리 범위

작업자 스레드

DoNotParallelizeAttribute

ResourceLockAttribute

종속성 테스트

시간 제한 속성

TimeoutAttribute

fixture 메서드에 시간 제한 적용

상호 협력에 의한 취소

특성 다시 시도

RetryAttribute

구성 옵션

사용자 지정 다시 시도 구현

조건부 실행 특성

ConditionBaseAttribute

OSConditionAttribute

지원되는 운영 체제

CIConditionAttribute

MemberConditionAttribute

ArchitectureConditionAttribute

ExecutableConditionAttribute

IgnoreAttribute

작업 항목에 연결

모범 사례

참고하십시오

피드백

추가 리소스

`STATestClassAttribute`

`STATestMethodAttribute`

`UITestMethodAttribute`

`ParallelizeAttribute`

`DoNotParallelizeAttribute`

`ResourceLockAttribute`

`TimeoutAttribute`

`RetryAttribute`

`ConditionBaseAttribute`

`OSConditionAttribute`

`CIConditionAttribute`

`MemberConditionAttribute`

`ArchitectureConditionAttribute`

`ExecutableConditionAttribute`

`IgnoreAttribute`