Tester l’exécution et le contrôle dans MSTest

MSTest fournit des attributs pour contrôler la façon dont les tests s’exécutent, notamment la parallélisation, les modèles de thread, les délais d’expiration, les nouvelles tentatives et l’exécution conditionnelle en fonction de la plateforme ou de l’environnement.

Attributs de thread

Les attributs de thread contrôlent le modèle de fil d'exécution utilisé par les méthodes de test. Ces attributs sont essentiels lors du test des composants COM, des éléments d’interface utilisateur ou du code avec des exigences de thread spécifiques.

STATestClassAttribute

Le STATestClassAttribute exécute toutes les méthodes de test d’une classe (y compris ClassInitialize et ClassCleanup) dans un thread unique cloisonné (STA). Utilisez cet attribut lors du test des objets COM qui nécessitent 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 exécute une méthode de test spécifique dans un thread unique cloisonné (STA). Utilisez cet attribut pour les tests individuels qui ont besoin de STA alors que d’autres tests de la classe ne le font pas.

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

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

Conserver le contexte STA pour les continuations asynchrones

À compter de MSTest 4.1, la STATestMethodAttribute propriété inclut une UseSTASynchronizationContext propriété qui garantit l’exécution des continuations asynchrones sur le même thread STA. Lorsqu’il est activé, l’attribut crée un code personnalisé SynchronizationContext qui publie des continuations vers le thread STA, qui est essentiel pour tester les composants de l’interface utilisateur qui nécessitent un thread STA tout au long de leurs opérations asynchrones.

[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

L’attribut UITestMethod planifie l’exécution des tests sur le thread d’interface utilisateur. Cet attribut est conçu pour tester les applications UWP et WinUI qui nécessitent un accès au thread d’interface utilisateur.

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

Attributs de parallélisation

Les attributs de parallélisation contrôlent si et comment les tests s’exécutent simultanément, ce qui améliore le temps d’exécution des tests.

ParallelizeAttribute

Par défaut, MSTest exécute des tests séquentiellement. L’attribut au niveau de l’assembly ParallelizeAttribute active l’exécution de test parallèle.

using Microsoft.VisualStudio.TestTools.UnitTesting;

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

Étendue de parallélisation

Threads de travail

La Workers propriété spécifie le nombre maximal de threads pour l’exécution parallèle :

• 0 (par défaut) : utiliser le nombre de processeurs logiques sur l’ordinateur
• Nombre entier positif : utilisez ce nombre de threads spécifiques

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

DoNotParallelizeAttribute

Le DoNotParallelizeAttribute empêche l’exécution parallèle pour des assemblies, classes ou méthodes spécifiques. Utilisez cet attribut lorsque les tests partagent l’état ou les ressources qui ne peuvent pas être accessibles en toute sécurité simultanément.

[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

Permet [ResourceLock] de sérialiser uniquement les tests qui accèdent à la même ressource nommée. Contrairement [DoNotParallelize]à , un verrou de ressource ne bloque pas les tests qui utilisent des ressources non liées. Le mode par défaut ReadWrite est exclusif, tandis que plusieurs tests qui demandent ResourceAccessMode.Read la même ressource peuvent s’exécuter ensemble.

private const string Database = "integration-database";

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

Pour un état à l’échelle du processus, utilisez les constantes dans WellKnownResources: CurrentDirectory, EnvironmentVariableset Console. Les noms de verrous utilisent l’égalité ordinale, l’égalité respectant la casse et les tests de coordonnées uniquement au sein d’une source ou d’un assembly de test. Ils ne coordonnent pas les tests à partir d’assemblys, de processus ou de machines distincts, même lorsque ces tests utilisent la même clé.

L’étendue de verrou suit l’étendue de parallélisation configurée :

• Avec ClassLevel, MSTest combine chaque verrou déclaré sur la classe et ses méthodes, puis conserve le mode le plus fort pour l’ensemble du cycle de vie de la classe.
• Avec MethodLevel, MSTest acquiert des verrous pour chaque test, y compris son initialisation et son nettoyage de test.
• Lorsque la parallélisation est désactivée, les verrous de ressources n’ont aucun effet.

Si un test utilise [DoNotParallelize]également , [DoNotParallelize] est prioritaire et MSTest ignore ses verrous de ressources. Un test qui attend qu’un verrou soutenu occupe un worker, de sorte que la contention de verrous lourds peut toujours réduire le débit.

Tester les dépendances

Utiliser [DependsOn] pour les tests d’intégration ou de bout en bout qui doivent s’exécuter après d’autres tests. Les dépendances forment un graphe acyclique dirigé, de sorte que les branches indépendantes peuvent toujours s’exécuter en parallèle.

[TestMethod]
public void CreateCart() { }

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

Appliquez plusieurs [DependsOn] attributs pour le ventilateur ou appliquez l’attribut à plusieurs tests pour le fan-out. Vous pouvez référencer une méthode dans la même classe, chaque test dans une autre classe ou une méthode dans une autre classe. Appliquez [DependsOn] à une classe de test pour donner à chaque test de cette classe la dépendance. Lorsqu’une dépendance cible un test piloté par les données, MSTest attend toutes ses lignes de données.

Par défaut, un prérequis ayant échoué ignore ses dépendants et l’ignorer se propage. MSTest évalue ProceedOnFailure par test dépendant, et non par périphérie. Pour exécuter une dépendance après l’échec des prérequis, définissez ProceedOnFailure = true chaque [DependsOn] déclaration pour ce test. Une déclaration laissée par défaut entraîne l’abandon de MSTest par défaut. MSTest signale les cycles de dépendance avant l’exécution et échoue les tests dans le cycle. Si une dépendance ne fait pas partie de l’exécution sélectionnée, MSTest avertit et ignore le bord manquant afin que les filtres et les exécutions à test unique fonctionnent toujours.

Avec Microsoft. Testing.Platform, vous pouvez également déclarer des dépendances sous mstest.execution.dependencies :testconfig.json

• Utiliser chains pour les séquences droites.
• Utilisation nodes pour fan-in, fan-out et proceedOnFailure.

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

Référencez un test avec son Namespace.Class.Method nom, ou référencez chaque test dans une classe avec Namespace.Class.*. MSTest fusionne les dépendances de configuration avec les dépendances déclarées par le biais d’attributs.

Le testconfig.json formulaire fonctionne uniquement avec Microsoft. Testing.Platform. L’attribut [DependsOn] fonctionne avec les deux Microsoft. Testing.Platform et VSTest. Pour la validation au moment de la génération, activez MSTEST0078.

Attributs de délai d’expiration

Les attributs de délai d’attente empêchent l’exécution indéfinie des tests et aident à identifier les problèmes de performances.

TimeoutAttribute

Spécifie TimeoutAttribute la durée maximale (en millisecondes) qu’une méthode de test ou de montage peut exécuter. Si l’exécution dépasse cette période, le test échoue.

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

Appliquer le délai d’expiration aux modèles de suffixe

Vous pouvez également appliquer des délais d’expiration aux méthodes d’initialisation et de nettoyage :

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

Annulation coopérative

Par défaut, MSTest encapsule chaque méthode de test chronométrée dans une tâche ou un thread distinct. Lorsque le délai d’expiration est atteint, l’infrastructure cesse d’observer le test, mais la tâche sous-jacente continue de s’exécuter en arrière-plan. Ce comportement peut entraîner des problèmes :

• La méthode de test continue d’accéder aux ressources et de muter l’état même après le délai d’expiration.
• L’exécution en arrière-plan peut entraîner des conditions de course affectant les tests suivants.
• Chaque méthode chronométrée entraîne une surcharge supplémentaire due à l’enveloppe de tâche/thread.

À compter de MSTest 3.6, utilisez la CooperativeCancellation propriété pour éviter ces problèmes. En mode coopératif, MSTest n’encapsule pas votre test dans une tâche supplémentaire. Au lieu de cela, lorsque le délai d’expiration est atteint, le cadre signale le jeton d’annulation. Votre code de test est chargé de vérifier régulièrement le jeton et de terminer correctement.

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

Avantages de l’annulation coopérative :

• Réduction de la surcharge de charge de travail (aucune enveloppe de tâche ou de fil d'exécution supplémentaire par test).
• Nettoyage des ressources plus propre, car votre code gère explicitement l’annulation.
• S’aligne sur les modèles d’annulation .NET standard.
• Comportement déterministe en évitant les conditions de course entre le code de test et l'exécution en arrière-plan non observée.

Attributs de nouvelle tentative

Les attributs de nouvelle tentative permettent de gérer les tests flaky en réexécutant automatiquement les tests ayant échoué.

RetryAttribute

Introduit dans MSTest 3.8, le RetryAttribute retente automatiquement les méthodes de test qui échouent ou expirent. Configurez le nombre maximal de tentatives, le délai entre celles-ci et la stratégie de recul.

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

Options de configuration

Implémentations de retries personnalisées

À compter de MSTest 3.8, créez une logique de nouvelle tentative personnalisée en héritant des éléments RetryBaseAttributesuivants :

public class CustomRetryAttribute : RetryBaseAttribute
{
    private readonly int _maxRetries;

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

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

Attributs d’exécution conditionnelle

Les attributs d’exécution conditionnelle contrôlent si les tests s’exécutent en fonction de conditions spécifiques telles que le système d’exploitation ou l’environnement CI.

ConditionBaseAttribute

Il ConditionBaseAttribute s’agit de la classe de base abstraite pour l’exécution conditionnelle. MSTest fournit plusieurs implémentations intégrées.

OSConditionAttribute

Les OSConditionAttribute exécutent ou ignorent les tests en fonction du système d’exploitation. Utilisez l’énumération OperatingSystems des indicateurs pour spécifier les systèmes d’exploitation qui s’appliquent.

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

Systèmes d'exploitation pris en charge

Combinez des systèmes d’exploitation avec l’opérateur OR au niveau du bit (|).

CIConditionAttribute

CIConditionAttribute exécute ou ignore les tests selon qu'il s'exécute dans un environnement d’intégration continue.

[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

Le MemberConditionAttribute, introduit dans MSTest 4.3, exécute ou ignore une classe de test ou une méthode de test en fonction de la valeur d’un ou de plusieurs membres statiques bool. Chaque membre est référencé par son type et son nom déclarés, et doit être public static, retourner boolet (pour les méthodes) être sans paramètre. Lorsque plusieurs membres sont spécifiés, ils sont combinés à un AND logique. Utilisez ConditionMode pour inverser la condition.

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

Introduit ArchitectureConditionAttributedans MSTest 4.3, exécute ou ignore les tests en fonction de l’architecture de processus. Utilisez l’énumération TestArchitectures d’indicateurs pour spécifier les architectures qui s’appliquent.

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

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

ExecutableConditionAttribute

Introduit ExecutableConditionAttributedans MSTest 4.3, exécute ou ignore les tests en fonction de la disponibilité d’un outil externe. Le test s’exécute uniquement lorsque l’exécutable spécifié peut être résolu ; vous pouvez éventuellement passer des arguments utilisés lors de la détection de l’outil.

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

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

IgnoreAttribute

L’objet IgnoreAttribute ignore inconditionnellement une classe de test ou une méthode. Si vous le souhaitez, fournissez une raison d’ignorer.

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

Lien vers des éléments de travail

Lorsque vous ignorez les tests en raison de problèmes connus, utilisez WorkItemAttribute ou GitHubWorkItemAttribute pour la traçabilité :

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

Meilleures pratiques

1. Utilisez la parallélisation judicieusement : activez la parallélisation pour les tests indépendants, mais utilisez-la DoNotParallelize pour les tests qui partagent l’état.

2. Définir les délais d’expiration appropriés : choisissez les délais d’expiration qui autorisent l’exécution normale, mais interceptent les tests bloqués. Envisagez d’utiliser des environnements CI lents.

3. Privilégiez l’annulation coopérative : utilisez l’annulation coopérative afin d'éviter la surcharge des wrappers de tâches supplémentaires et empêcher l’exécution en arrière-plan des tests qui ont expiré. Activez l’analyseur MSTEST0045 pour appliquer cette pratique.

4. Déclaration des tests ignorés : fournissez toujours une raison et une référence à l'élément de travail lorsque vous ignorez les tests.

5. Utilisez les tentatives supplémentaires avec parcimonie : résolvez la cause première des tests instables plutôt que de vous appuyer sur les tentatives supplémentaires.

6. Testez le code propre au système d’exploitation de manière appropriée : utilisez-le OSCondition pour exécuter des tests spécifiques à la plateforme uniquement lorsqu’ils sont applicables.

Voir aussi

• Configurer MSTest
• Cycle de vie des tests
• Écrire des tests dans MSTest
• MSTEST0001 : utiliser l’attribut Parallelize
• MSTEST0041 : utiliser des attributs basés sur des conditions avec une classe de test
• MSTEST0043 : Utiliser l’attribut nouvelle tentative sur la méthode de test
• MSTEST0045 : utiliser l’annulation coopérative pour le délai d’expiration
• MSTEST0059 : utiliser l’attribut Parallelize correctement
• MSTEST0061 : Utiliser l’attribut OSCondition au lieu de la vérification du runtime