Execução e controlo de testes no MSTest

O MSTest fornece atributos para controlar como os testes são executados, incluindo paralelização, modelos de threading, timeouts, tentativas e execução condicional baseada na plataforma ou ambiente.

Atributos de threading

Os atributos de threading controlam quais os métodos de teste do modelo de threads usados. Estes atributos são essenciais ao testar componentes COM, elementos de interface ou código com requisitos específicos de threading.

STATestClassAttribute

Executa todos os métodos de teste de uma classe, incluindo STATestClassAttribute e ClassInitialize, num único thread (STA). Use este atributo ao testar objetos COM que requerem STA.

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

STATestMethodAttribute

Executa STATestMethodAttribute um método de teste específico num apartamento de thread única. Usa este atributo para testes individuais que precisam de STA, enquanto outros testes na classe não precisam.

[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 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 sejam executadas no mesmo thread STA. Quando habilitado, o atributo cria um SynchronizationContext personalizado que publica continuações de volta para a thread STA, o que é essencial para testar componentes da interface que requerem encadeamento STA durante 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 de testes no thread da interface. Este atributo foi concebido para testar aplicações UWP e WinUI que requerem acesso à thread da interface.

[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 correm em simultâneo, melhorando o tempo de execução dos testes.

Configurar paralelização

O MSTest executa testes sequencialmente dentro de cada conjunto de teste por defeito. Use um dos seguintes mecanismos para ativar ou desativar explicitamente a paralelização em montagem:

ParallelizeAttribute

Por defeito, o MSTest executa testes sequencialmente. O atributo ParallelizeAttribute ao nível de montagem permite a execução paralela de testes.

using Microsoft.VisualStudio.TestTools.UnitTesting;

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

Âmbito de paralelização

Fios de trabalhadores

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

• 0 (por padrão): Usar o número de processadores lógicos na máquina
• 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 DoNotParallelizeAttribute a execução paralela para assemblies, classes ou métodos específicos. Use este atributo quando os testes partilham estados ou recursos que não podem ser acedidos em segurança em simultâneo.

Quando ativas a paralelização em montagem, o MSTest particiona cada fonte de teste (assembly) em testes paralelizáveis e não paralelizáveis. O MSTest executa primeiro o conjunto passível de execução em paralelo e, em seguida, executa o conjunto DoNotParallelize um teste de cada vez no final da execução dessa origem. Em execuções que incluem múltiplas fontes de teste, cada fonte tem a sua própria cauda diferida. Como os testes diferidos não podem sobrepor-se a outros testes na mesma origem, um teste diferido lento normalmente aumenta o caminho crítico dessa origem em aproximadamente tanto quanto a sua própria duração.

Como o MSTest executa testes diferidos apenas após o término da fase paralelizável, uma execução cancelada ou abortada pode terminar antes de o MSTest executar testes diferidos. A ordem de execução aqui descrita é um detalhe interno de implementação e não é um contrato público. Pode mudar numa futura versão 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 apenas testes que acedam ao mesmo recurso nomeado. Ao contrário de [DoNotParallelize], um bloqueio de recursos não bloqueia testes que usam recursos não relacionados. O modo padrão ReadWrite é exclusivo, enquanto múltiplos testes que solicitam ResourceAccessMode.Read o mesmo recurso podem correr em conjunto.

private const string Database = "integration-database";

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

Para o estado em todo o processo, use as constantes em WellKnownResources: CurrentDirectory, EnvironmentVariables, e Console. Os nomes de bloqueio usam apenas comparações ordinais, sensíveis a maiúsculas e minúsculas, e testes de coordenadas dentro de uma única fonte de teste ou assemblagem. Eles não coordenam testes de montagens, processos ou máquinas separadas, mesmo quando esses testes usam a mesma chave.

O âmbito do bloqueio segue o âmbito de paralelização configurado:

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

Se um teste também usar [DoNotParallelize], [DoNotParallelize] tem precedência e o MSTest ignora os seus bloqueios de recursos. Um teste que espera por um bloqueio contestado ocupa um trabalhador, pelo que uma contenção pesada de bloqueio ainda pode reduzir o rendimento.

Dependências de teste

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

[TestMethod]
public void CreateCart() { }

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

Aplique múltiplos atributos [DependsOn] para fan-in, ou aplique o atributo a vários testes para fan-out. Pode referenciar um método na mesma classe, todos os testes noutra classe ou um método noutra classe. Aplique [DependsOn] a uma classe de teste para fornecer essa dependência a todos os testes dessa classe. Quando uma dependência tem como alvo um teste orientado por dados, o MSTest espera por todas as suas linhas de dados.

Por predefinição, um pré-requisito que falha faz com que os seus dependentes sejam ignorados, e essa omissão propaga-se. O MSTest avalia ProceedOnFailure por teste dependente, não por aresta. Para executar um teste dependente após a falha dos pré-requisitos, define ProceedOnFailure = true em todas as declarações [DependsOn] desse teste. Uma declaração deixada no padrão faz com que o MSTest ignore o dependente. O MSTest reporta os ciclos de dependência antes da execução e falha os testes nesse ciclo. Se uma dependência não fizer parte da execução selecionada, o MSTest avisa e ignora a aresta em falta, por isso filtros e execuções de teste único continuam a funcionar.

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

• Use chains para sequências retas.
• Utilize 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 }]
  }}}
}

Referenciar um teste pelo seu Namespace.Class.Method nome, ou referir todos os testes de uma classe com Namespace.Class.*. O MSTest funde dependências de configuração com dependências declaradas através de atributos.

A testconfig.json forma funciona apenas com Microsoft.Testing.Platform. O [DependsOn] atributo funciona tanto com a Microsoft. Testing.Platform e VSTest. Para validação em tempo de construção, ative MSTEST0078.

Atributos de timeout

Os atributos de timeout impedem que os testes corram indefinidamente e ajudam a identificar problemas de desempenho.

TimeoutAttribute

Especifica TimeoutAttribute o tempo máximo (em milissegundos) que um método de teste ou fixture pode executar. Se a execução exceder esse tempo, o teste falha.

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

Aplicar tempo de espera aos métodos de fixação

Também pode aplicar timeouts 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 cooperativo

Por defeito, o MSTest envolve cada método de teste cronometrado numa tarefa ou numa thread separada. Quando o timeout é atingido, o framework deixa de observar o teste, mas a tarefa subjacente continua a correr em segundo plano. Este comportamento pode causar problemas:

• O método de teste continua a aceder a recursos e a mutar o estado mesmo após o timeout.
• A execução em segundo plano pode levar a que as condições da corrida afetem testes subsequentes.
• Cada método temporizado implica sobrecarga adicional do wrapper da tarefa/thread.

A partir do MSTest 3.6, utilize a CooperativeCancellation propriedade para evitar estes problemas. No modo cooperativo, o MSTest não envolve o teste numa tarefa extra. Em vez disso, quando o timeout é atingido o framework sinaliza o token de cancelamento. O teu código de teste é responsável por verificar o token regularmente e terminar 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 overhead de desempenho (sem tarefas/thread wrapper extra por teste).
• Limpeza de recursos mais limpa, já que o seu código trata explicitamente do cancelamento.
• Alinha-se com os padrões padrão de cancelamento do .NET.
• Comportamento determinístico evitando condições de corrida entre código de teste e execução em segundo plano não observada.

Atributos de tentativa

Os atributos Retry ajudam a lidar com testes instáveis ao reexecutar automaticamente testes falhados.

RetryAttribute

O RetryAttribute, introduzido no MSTest 3.8, reexecuta automaticamente métodos de teste que falham ou desistem. Configure o máximo de tentativas de retentativa, o atraso entre tentativas e a estratégia de backoff.

[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 personalizadas de novas tentativas

A partir do MSTest 3.8, crie lógica de retry personalizada herdando de RetryBaseAttribute:

A partir do MSTest 4.4, RetryResult.AllResults expõe os arrays de resultados de cada tentativa na ordem em que foram adicionados. O MTP reporta tentativas anteriores como superadas, enquanto o VSTest recebe apenas o resultado final. O MSTest só tenta novamente quando uma tentativa contém um resultado falhado ou com tempo de expiração. Um resultado inconclusivo, por si só, interrompe a sequência de tentativas.

O atributo --retry-failed-tests ao nível do processo e um atributo de repetição do MSTest aplicam-se a níveis diferentes. Os seus efeitos são multiplicativos porque cada tentativa ao nível do processo pode executar a sequência completa de novas tentativas 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 operativo ou o ambiente de CI.

ConditionBaseAttribute

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

OSConditionAttribute

O OSConditionAttribute faz executar ou ignorar testes com base no sistema operativo. Utilize o enum de sinalizadores OperatingSystems para especificar quais sistemas operativos são aplicáveis.

[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 operativos suportados

Combine sistemas operativos utilizando o operador OR binário (|).

CIConditionAttribute

Executa ou ignora testes baseando-se em se estão a ser realizados num 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 pelo seu tipo declarante e nome, e deve ser public static, return bool, e (para métodos) ser sem parâmetros. Quando vários membros são especificados, 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. Usa os TestArchitectures flags enum para especificar que 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 salta testes consoante a disponibilidade de uma ferramenta externa. O teste só é executado quando o executável especificado pode ser resolvido; Pode, opcionalmente, 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 ignora incondicionalmente uma classe ou método de teste. Opcionalmente, forneça uma razão 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
    }
}

Melhores práticas

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

2. Defina tempos limites apropriados: Escolha tempos limites que permitam a execução normal mas apanhem testes presos. Considere ambientes de CI lentos.

3. Prefira cancelamento cooperativo: Use cancelamento cooperativo para evitar a sobrecarga de wrappers de tarefas extra e evitar a execução em segundo plano de testes com tempo de expiração. Ative o analisador MSTEST0045 para aplicar esta prática.

4. Documente os testes ignorados: Dê sempre uma razão e uma referência de item de trabalho ao ignorar testes.

5. Utilize as tentativas com moderação: Aborde a causa raiz dos testes instáveis em vez de se apoiar em tentativas.

6. Teste código específico do sistema operativo de forma adequada: Use OSCondition para executar testes específicos da plataforma apenas quando são aplicáveis.

Consulte também

• Configurar MSTest
• Ciclo de vida dos testes
• Escrever testes no MSTest
• MSTEST0001: Usar o atributo Paralelizar
• MSTEST0041: Usar atributos baseados em condição com a classe de teste
• MSTEST0043: Usar o atributo retry no método de teste
• MSTEST0045: Use o cancelamento cooperativo para tempo limite
• MSTEST0059: Usar corretamente o atributo Parallelize
• MSTEST0061: Usar o atributo OSCondition em vez da verificação em tempo de execução