Testar a execução e o controle no MSTest

O MSTest fornece atributos para controlar como os testes são executados, incluindo paralelização, modelos de threading, tempos limite, repetições e execução condicional com base na plataforma ou no ambiente.

Atributos de threads

Os atributos de threads controlam quais métodos de teste de modelo de thread usar. Esses atributos são essenciais ao testar componentes COM, elementos de interface do usuário ou código com requisitos de threading específicos.

STATestClassAttribute

STATestClassAttribute executa todos os métodos de teste em uma classe (incluindo ClassInitialize e ClassCleanup) em um STA (modelo Apartment Threading único). Use esse atributo ao testar objetos COM que exigem STA.

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

STATestMethodAttribute

STATestMethodAttribute executa um método de teste específico em um modelo Apartment Threading único. Use esse atributo para testes individuais que precisam de STA, enquanto outros testes na classe não.

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

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

Preservar o contexto de STA para continuações assíncronas

A partir do MSTest 4.1, o STATestMethodAttribute inclui uma propriedade UseSTASynchronizationContext que garante que as continuações assíncronas são executadas no mesmo thread STA. Quando habilitado, o atributo cria um SynchronizationContext personalizado que envia continuações de volta para o thread STA, o que é essencial para testar componentes da interface do usuário que requerem thread STA em todas as operações assíncronas.

[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);
    }
}

UITestMethodAttribute

O UITestMethod atributo agenda a execução do teste no thread da interface do usuário. Esse atributo foi projetado para testar aplicativos UWP e WinUI que exigem acesso de thread da UI.

[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);
    }
}

Atributos de paralelização

Os atributos de paralelização controlam se e como os testes são executados simultaneamente, melhorando o tempo de execução do teste.

Configurar paralelização

O MSTest executa testes sequencialmente em cada assembly de teste por padrão. Use um dos seguintes mecanismos para habilitar ou desabilitar explicitamente a paralelização em assembly:

ParallelizeAttribute

Por padrão, o MSTest executa testes sequencialmente. O ParallelizeAttribute atributo no nível do assembly habilita a execução de teste paralela.

using Microsoft.VisualStudio.TestTools.UnitTesting;

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

Escopo de paralelização

Threads de trabalho

A Workers propriedade especifica o número máximo de threads para execução paralela:

• 0 (padrão): use o número de processadores lógicos no computador
• Qualquer número inteiro positivo: use esse número específico de threads

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

DoNotParallelizeAttribute

Impede a DoNotParallelizeAttribute execução paralela de assemblies, classes ou métodos específicos. Use esse atributo ao testar o estado de compartilhamento ou os recursos que não podem ser acessados simultaneamente com segurança.

Quando você habilita a paralelização no nível do assembly, o MSTest particiona cada fonte de teste (assembly) em testes paralelizáveis e testes não paralelizáveis. O MSTest executa primeiro o conjunto paralelizável e, em seguida, executa o conjunto DoNotParallelize um teste por vez ao final da execução dessa fonte. Em execuções que incluem várias fontes de teste, cada fonte tem sua própria cauda adiada. Como os testes diferidos não podem se sobrepor a outros testes na mesma fonte, um teste diferido lento geralmente aumenta o caminho crítico da fonte em aproximadamente sua própria duração.

Como o MSTest executa testes adiados somente após a conclusão da fase paralelizável, uma execução cancelada ou anulada pode terminar antes que o MSTest execute testes adiados. A ordem de execução descrita aqui é um detalhe de implementação interna e não é um contrato público. Ele pode mudar em uma versão futura do 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
    }
}

ResourceLockAttribute

Use [ResourceLock] para serializar somente testes que acessam o mesmo recurso nomeado. Ao contrário de [DoNotParallelize], um bloqueio de recurso não bloqueia testes que usam recursos não relacionados. O modo padrão ReadWrite é exclusivo, enquanto vários testes que solicitam ResourceAccessMode.Read o mesmo recurso podem ser executados juntos.

private const string Database = "integration-database";

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

Para o estado de todo o processo, use as constantes em WellKnownResources: CurrentDirectory, EnvironmentVariables e Console. Os nomes de lock usam testes de igualdade ordinal, com diferenciação entre maiúsculas e minúsculas, e testes de coordenadas apenas dentro de uma mesma origem de teste ou assembly. Eles não coordenam testes de assemblies, processos ou computadores separados, mesmo quando esses testes usam a mesma chave.

O escopo de bloqueio segue o escopo de paralelização configurado:

• Com ClassLevel, o MSTest combina todos os bloqueios declarados na classe e em seus métodos e, em seguida, mantém o modo mais restritivo durante todo o ciclo de vida da classe.
• Com MethodLevel, o MSTest adquire bloqueios para cada teste, incluindo a inicialização e a limpeza de cada teste.
• Quando a paralelização é desabilitada, os bloqueios de recursos não têm efeito.

Se um teste também usar [DoNotParallelize], [DoNotParallelize] tem precedência e MSTest ignora seus bloqueios de recursos. Um teste que aguarda um bloqueio travado ocupa um trabalho, de modo que a contenção de bloqueio pesado ainda pode reduzir a taxa de transferência.

Testar dependências

Use [DependsOn] para testes de integração ou de ponta a ponta que devem ser executados após outros testes. As dependências formam um grafo acíclico direcionado, portanto as ramificações independentes ainda podem ser executadas em paralelo.

[TestMethod]
public void CreateCart() { }

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

Aplique vários atributos [DependsOn] para fan-in ou aplique o atributo a vários testes para fan-out. Você pode fazer referência a um método na mesma classe, a todos os testes de outra classe ou a um método de outra classe. Aplique [DependsOn] a uma classe de teste para fornecer a dependência a cada teste dessa classe. Quando uma dependência tem como destino um teste orientado por dados, MSTest aguarda todas as suas linhas de dados.

Por padrão, um pré-requisito com falha faz com que seus dependentes sejam ignorados, e essa omissão se propaga. O MSTest avalia ProceedOnFailure por teste dependente, não por aresta. Para executar uma dependência mesmo após a falha dos pré-requisitos, defina ProceedOnFailure = true em cada declaração [DependsOn] desse teste. Uma declaração deixada no padrão faz com que o MSTest ignore o dependente. O MSTest relata ciclos de dependência antes da execução e falha nos testes no ciclo. Se uma dependência não fizer parte da execução selecionada, o MSTest avisará e ignorará a borda ausente para que os filtros e as execuções de teste único ainda funcionem.

Com Microsoft.Testing.Platform, você também pode declarar dependências em mstest.execution.dependencies em testconfig.json:

• Use chains para sequências retas.
• Use nodes para fan-in, fan-out e proceedOnFailure.

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

Faça referência a um teste com seu Namespace.Class.Method nome ou faça referência a cada teste em uma classe com Namespace.Class.*. O MSTest mescla dependências de configuração com dependências declaradas por meio de atributos.

O testconfig.json formulário funciona apenas com Microsoft. Testing.Platform. O [DependsOn] atributo funciona com Microsoft. Testing.Platform e VSTest. Para validação em tempo de build, habilite MSTEST0078.

Atributos de tempo limite

Os atributos de tempo limite impedem que os testes sejam executados indefinidamente e ajudam a identificar problemas de desempenho.

TimeoutAttribute

TimeoutAttribute especifica o tempo máximo (em milissegundos) que um método de teste ou acessório pode executar. Se a execução exceder esse tempo, o teste falhará.

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

Aplicar tempo limite aos métodos de acessório

Você também pode aplicar tempos limite aos métodos de inicialização e limpeza:

[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
    }
}

Cancelamento de cooperativa

Por padrão, o MSTest encapsula cada método de teste cronometrado em uma tarefa ou thread separado. Quando o tempo limite é atingido, a estrutura para de observar o teste, mas a tarefa subjacente continua em execução em segundo plano. Esse comportamento pode causar problemas:

• O método de teste continua a acessar recursos e alterar o estado mesmo após o tempo limite.
• A execução em segundo plano pode levar a condições de corrida que afetam os testes subsequentes.
• Cada método cronometrado gera uma sobrecarga adicional do wrapper de tarefa/thread.

A partir do MSTest 3.6, use a CooperativeCancellation propriedade para evitar esses problemas. No modo cooperativo, o MSTest não encapsula o teste em uma tarefa extra. Em vez disso, quando o tempo limite é atingido, a estrutura sinaliza o token de cancelamento. Seu código de teste é responsável por verificar o token regularmente e encerrar de forma elegante.

[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
        }
    }
}

Benefícios do cancelamento cooperativo:

• Menor sobrecarga de desempenho (sem necessidade de um wrapper de tarefa ou thread extra por teste).
• Limpeza de recursos mais limpa, já que seu código manipula o cancelamento explicitamente.
• Alinha-se aos padrões padrão de cancelamento do .NET.
• Comportamento determinístico ao evitar condições de corrida entre o código de teste e a execução em segundo plano não observada.

Tentar novamente atributos

Os atributos de repetição ajudam a lidar com testes instáveis ao executar automaticamente os testes que falharam.

RetryAttribute

RetryAttribute, introduzido no MSTest 3.8, repete automaticamente os métodos de teste que falham ou alcançam tempo limite. Configure o máximo de tentativas de repetição, atraso entre novas tentativas e estratégia de retirada.

[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
    }
}

Opções de configuração

Implementações de repetição personalizadas

A partir do MSTest 3.8, crie uma lógica de repetição personalizada herdando de RetryBaseAttribute:

A partir do MSTest 4.4, RetryResult.AllResults expõe as matrizes de resultados de cada tentativa na ordem em que foram adicionadas. O MTP relata tentativas anteriores como substituídas, enquanto o VSTest recebe apenas o resultado final. O MSTest tenta novamente somente quando uma tentativa contém um resultado com falha ou tempo limite. Um resultado inconclusivo por si só interrompe a sequência de repetição.

O --retry-failed-tests em nível de processo e um atributo de repetição do MSTest se aplicam em níveis diferentes. Seus efeitos são multiplicativos porque cada tentativa em nível de processo pode executar a sequência de repetição completa do atributo.

public class CustomRetryAttribute : RetryBaseAttribute
{
    private readonly int _maxRetries;

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

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

Atributos de execução condicional

Os atributos de execução condicional controlam se os testes são executados com base em condições específicas, como o sistema operacional ou o ambiente de CI.

ConditionBaseAttribute

A ConditionBaseAttribute classe base é abstrata para execução condicional. O MSTest fornece várias implementações internas.

OSConditionAttribute

Os testes do OSConditionAttribute são executados ou ignorados com base no sistema operacional. Use a enumeração de sinalizadores OperatingSystems para especificar quais sistemas operacionais se aplicam.

[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
    }
}

Sistemas operacionais com suporte

Combine sistemas operacionais com o operador OR binário (|).

CIConditionAttribute

CIConditionAttribute são executados ou ignorados com base na execução em um ambiente de integração contínua.

[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

O MemberConditionAttribute, introduzido no MSTest 4.3, executa ou ignora uma classe de teste ou método de teste com base no valor de um ou mais membros estáticos bool . Cada membro é referenciado por seu tipo e nome de declaração e deve ser public static, retornar boole (para métodos) ser sem parâmetros. Quando vários membros são especificados, eles são combinados com um AND lógico. Use ConditionMode para inverter a condição.

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()
    {
    }
}

ArchitectureConditionAttribute

O ArchitectureConditionAttribute, introduzido no MSTest 4.3, executa ou ignora testes com base na arquitetura do processo. Use a enumeração de sinalizadores TestArchitectures para especificar quais arquiteturas se aplicam.

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

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

ExecutableConditionAttribute

O ExecutableConditionAttribute, introduzido no MSTest 4.3, executa ou ignora testes com base em se uma ferramenta externa está disponível. O teste é executado somente quando o executável especificado pode ser resolvido; opcionalmente, você pode passar argumentos que são usados ao sondar a ferramenta.

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

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

IgnoreAttribute

O IgnoreAttribute pula incondicionalmente uma classe ou método de teste. Opcionalmente, forneça um motivo para ignorar.

[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
}

Link para itens de trabalho

Ao ignorar testes devido a problemas conhecidos, use WorkItemAttribute ou GitHubWorkItemAttribute para rastreabilidade:

[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
    }
}

Práticas recomendadas

1. Use a paralelização com sabedoria: habilite a paralelização para testes independentes, mas use DoNotParallelize para testes que compartilham o estado.

2. Definir tempos limite apropriados: escolha tempos limite que possibilitam a execução normal, mas detectam testes travados. Considere ambientes de CI lentos.

3. Prefira o cancelamento cooperativo: use o cancelamento cooperativo para evitar a sobrecarga de wrappers de tarefas extras e impedir a execução em segundo plano de testes com tempo limite. Habilite o analisador MSTEST0045 para impor essa prática.

4. Documente testes ignorados: sempre forneça um motivo e uma referência de item de trabalho ao ignorar testes.

5. Use novas tentativas com moderação: resolva a causa raiz de testes instáveis em vez de depender de novas tentativas.

6. Testar o código específico do sistema operacional adequadamente: use OSCondition para executar testes específicos da plataforma somente quando eles forem aplicáveis.

Consulte também

• Configurar o MSTest
• Ciclo de vida de teste
• Gravar testes no MSTest
• MSTEST0001: usar o atributo Parallelize
• MSTEST0041: usar atributos baseados em condição com classe de teste
• MSTEST0043: usar o atributo de repetição no método de teste
• MSTEST0045: usar cancelamento cooperativo para tempo limite
• MSTEST0059: usar o atributo Parallelize corretamente
• MSTEST0061: usar o atributo OSCondition em vez da verificação de runtime