Uitvoering en beheer testen in MSTest

MSTest biedt kenmerken om te bepalen hoe tests worden uitgevoerd, waaronder parallellisatie, threadingmodellen, time-outs, nieuwe pogingen en voorwaardelijke uitvoering op basis van platform of omgeving.

Threading-kenmerken

Threading-kenmerken bepalen welke threadmodeltestmethoden worden gebruikt. Deze kenmerken zijn essentieel bij het testen van COM-onderdelen, UI-elementen of code met specifieke threadingvereisten.

STATestClassAttribute

Hiermee STATestClassAttribute worden alle testmethoden uitgevoerd in een klasse (inclusief ClassInitialize en ClassCleanup) in een appartement met één thread (STA). Gebruik dit kenmerk bij het testen van COM-objecten waarvoor STA is vereist.

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

STATestMethodAttribute

De STATestMethodAttribute uitvoering van een specifieke testmethode in een appartement met één thread. Gebruik dit kenmerk voor afzonderlijke tests die STA nodig hebben terwijl andere tests in de klasse dat niet doen.

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

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

STA-context behouden voor asynchrone vervolgen

Vanaf MSTest 4.1 bevat de STATestMethodAttribute eigenschap een UseSTASynchronizationContext eigenschap die ervoor zorgt dat asynchrone vervolgen worden uitgevoerd op dezelfde STA-thread. Wanneer dit is ingeschakeld, wordt met het kenmerk een aangepast kenmerk SynchronizationContext gemaakt dat vervolgen terugzet naar de STA-thread, wat essentieel is voor het testen van UI-onderdelen waarvoor STA-threading is vereist tijdens hun asynchrone bewerkingen.

[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

Het UITestMethod kenmerk plant de testuitvoering op de UI-thread. Dit kenmerk is ontworpen voor het testen van UWP- en WinUI-toepassingen waarvoor ui-threadtoegang is vereist.

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

Parallellisatiekenmerken

Parallellisatiekenmerken bepalen of en hoe tests gelijktijdig worden uitgevoerd, waardoor de uitvoeringstijd van de test wordt verbeterd.

ParallelizeAttribute

MSTest voert standaard opeenvolgend tests uit. Het ParallelizeAttribute kenmerk op assemblyniveau maakt parallelle testuitvoering mogelijk.

using Microsoft.VisualStudio.TestTools.UnitTesting;

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

Parallellisatiebereik

Werkerthreads

De Workers eigenschap geeft het maximum aantal threads op voor parallelle uitvoering:

• 0 (standaard): Gebruik het aantal logische processors op de computer
• Een positief geheel getal: gebruik dat specifieke aantal threads

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

DoNotParallelizeAttribute

Hiermee DoNotParallelizeAttribute voorkomt u parallelle uitvoering voor specifieke assembly's, klassen of methoden. Gebruik dit kenmerk wanneer tests de status of resources delen die niet veilig gelijktijdig kunnen worden geopend.

[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

Gebruik [ResourceLock] dit om alleen tests te serialiseren die toegang hebben tot dezelfde benoemde resource. In tegenstelling tot [DoNotParallelize], blokkeert een resourcevergrendeling geen tests die gebruikmaken van niet-gerelateerde resources. De standaardmodus ReadWrite is exclusief, terwijl meerdere tests die voor dezelfde resource worden aangevraagd ResourceAccessMode.Read , samen kunnen worden uitgevoerd.

private const string Database = "integration-database";

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

Voor procesbrede status gebruikt u de constanten in WellKnownResources: CurrentDirectory, EnvironmentVariablesen Console. Vergrendelingsnamen maken gebruik van ordinale, hoofdlettergevoelige gelijkheids- en coördinaattests binnen één testbron of assembly. Ze coördineren geen tests van afzonderlijke assembly's, processen of machines, zelfs niet wanneer deze tests dezelfde sleutel gebruiken.

Vergrendelingsbereik volgt het geconfigureerde parallellisatiebereik:

• Met ClassLevel, msTest combineert elke vergrendeling die is gedeclareerd op de klasse en de bijbehorende methoden, en houdt vervolgens de sterkste modus voor de hele klaslevenscyclus.
• Met MethodLevel, MSTest verkrijgt vergrendelingen voor elke test, inclusief de test initialisatie en opschoning.
• Wanneer parallellisatie is uitgeschakeld, hebben resourcevergrendelingen geen effect.

Als een test ook wordt gebruikt [DoNotParallelize], [DoNotParallelize] heeft prioriteit en negeert MSTest de resourcevergrendelingen. Een test die wacht op een gestreden vergrendeling neemt een werkrol in beslag, zodat zware vergrendelingsconflicten nog steeds de doorvoer kunnen verminderen.

Afhankelijkheden testen

Gebruik [DependsOn] deze functie voor integratie of end-to-end tests die na andere tests moeten worden uitgevoerd. Afhankelijkheden vormen een gerichte acyclische grafiek, zodat onafhankelijke vertakkingen nog steeds parallel kunnen worden uitgevoerd.

[TestMethod]
public void CreateCart() { }

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

Pas meerdere [DependsOn] kenmerken toe voor fan-in of pas het kenmerk toe op verschillende tests voor fan-out. U kunt verwijzen naar een methode in dezelfde klasse, elke test in een andere klasse of een methode in een andere klasse. Pas [DependsOn] toe op een testklasse om elke test in die klasse de afhankelijkheid te geven. Wanneer een afhankelijkheid is gericht op een gegevensgestuurde test, wacht MSTest op alle gegevensrijen.

Standaard slaat een mislukte vereiste de afhankelijke onderdelen over en wordt de skip doorgegeven. MSTest evalueert per afhankelijke ProceedOnFailure test, niet per rand. Als u een afhankelijke voorwaarde wilt uitvoeren na mislukte vereisten, stelt u ProceedOnFailure = true elke [DependsOn] declaratie voor die test in. Eén declaratie links op de standaardinstelling zorgt ervoor dat MSTest de afhankelijke gegevens overslaat. MSTest rapporteert afhankelijkheidscycli vóór uitvoering en mislukt de tests in de cyclus. Als een afhankelijkheid geen deel uitmaakt van de geselecteerde uitvoering, waarschuwt en negeert MSTest de ontbrekende rand, zodat filters en uitvoeringen met één test nog steeds werken.

Met Microsoft. Testing.Platform, u kunt ook afhankelijkheden declareren ondermstest.execution.dependencies:testconfig.json

• Gebruik chains voor rechte reeksen.
• Gebruiken nodes voor fan-in, fan-out, en proceedOnFailure.

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

Verwijs naar één test met de Namespace.Class.Method naam of verwijs naar elke test in een klasse met Namespace.Class.*. MSTest voegt configuratieafhankelijkheden samen met afhankelijkheden die zijn gedeclareerd via kenmerken.

Het testconfig.json formulier werkt alleen met Microsoft. Testing.Platform. Het [DependsOn] kenmerk werkt met beide Microsoft. Testing.Platform en VSTest. Schakel MSTEST0078 in voor validatie tijdens de build.

Time-outkenmerken

Time-outkenmerken voorkomen dat tests voor onbepaalde tijd worden uitgevoerd en helpen bij het identificeren van prestatieproblemen.

TimeoutAttribute

De TimeoutAttribute specificeert de maximale tijd (in milliseconden) die een test- of fixture-methode kan draaien. Als de uitvoering deze tijdslimiet overschrijdt, mislukt de test.

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

Time-out toepassen op armaturenmethoden

U kunt ook time-outs toepassen op initialisatie- en opschoonmethoden:

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

Coöperatieve annulering

MSTest verpakt standaard elke getimede testmethode in een afzonderlijke taak of thread. Wanneer de time-out is bereikt, stopt het framework met het observeren van de test, maar blijft de onderliggende taak op de achtergrond actief. Dit gedrag kan problemen veroorzaken:

• De testmethode blijft toegang krijgen tot resources en de toestand wijzigen, zelfs na een time-out.
• Uitvoering op de achtergrond kan leiden tot racevoorwaarden die van invloed zijn op volgende tests.
• Elke getimede methode brengt extra overhead met zich mee van de taak/thread-wrapper.

Gebruik vanaf MSTest 3.6 de CooperativeCancellation eigenschap om deze problemen te voorkomen. In de coöperatieve modus verpakt MSTest uw test niet in een extra taak. Wanneer de time-out wordt bereikt, geeft het framework in plaats daarvan het annuleringstoken aan. Uw testcode is verantwoordelijk voor het regelmatig controleren van het token en het op een goede manier beëindigen.

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

Voordelen van collectieve annulering:

• Lagere overhead voor performance (geen extra taak/thread-wrapper per test).
• Efficiëntere opruiming van resources omdat uw code expliciet omgaat met annulering.
• Wordt uitgelijnd met standaard .NET-annuleringspatronen.
• Deterministisch gedrag door racecondities tussen testcode en niet-waargenomen achtergronduitvoering te voorkomen.

Kenmerken opnieuw proberen

Kenmerken voor opnieuw proberen helpen bij het afhandelen van flaky tests door mislukte tests automatisch opnieuw uit te voeren.

RetryAttribute

De RetryAttribute, geïntroduceerd in MSTest 3.8, probeert automatisch testmethoden opnieuw die mislukken of een time-out krijgen. Configureer het maximale aantal pogingen, de vertraging tussen pogingen en de back-off-strategie.

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

Configuratieopties

Aangepaste implementaties voor opnieuw proberen

Maak vanaf MSTest 3.8 aangepaste logica voor opnieuw proberen door deze over te nemen van RetryBaseAttribute:

public class CustomRetryAttribute : RetryBaseAttribute
{
    private readonly int _maxRetries;

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

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

Kenmerken voor voorwaardelijke uitvoering

Kenmerken voor voorwaardelijke uitvoering bepalen of tests worden uitgevoerd op basis van specifieke voorwaarden, zoals besturingssysteem of CI-omgeving.

ConditionBaseAttribute

Dit ConditionBaseAttribute is de abstracte basisklasse voor voorwaardelijke uitvoering. MSTest biedt verschillende ingebouwde implementaties.

OSConditionAttribute

De OSConditionAttribute voert of slaat tests over afhankelijk van het besturingssysteem. Gebruik de OperatingSystems markeringenum om op te geven welke besturingssystemen van toepassing zijn.

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

Ondersteunde besturingssystemen

Combineer besturingssystemen met de bitsgewijze OR-operator (|).

CIConditionAttribute

De CIConditionAttribute voert tests uit of slaat ze over, afhankelijk van of ze worden uitgevoerd in een continue integratieomgeving.

[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

De MemberConditionAttribute, geïntroduceerd in MSTest 4.3, voert een testklasse of testmethode uit of slaat deze over op basis van de waarde van een of meer statische bool leden. Elk lid wordt aangeduid met het declarerende type en de naam, en moet public static zijn, bool retourneren en (voor methoden) parameterloos zijn. Wanneer meerdere leden worden opgegeven, worden ze gecombineerd met een logische AND. Gebruik ConditionMode om de voorwaarde om te keren.

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

De ArchitectureConditionAttribute, geïntroduceerd in MSTest 4.3, voert tests uit of slaat deze over op basis van de procesarchitectuur. Gebruik de TestArchitectures markeringenum om op te geven welke architecturen van toepassing zijn.

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

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

ExecutableConditionAttribute

De ExecutableConditionAttribute, geïntroduceerd in MSTest 4.3, voert tests uit of slaat deze over op basis van of een extern hulpprogramma beschikbaar is. De test wordt alleen uitgevoerd wanneer het opgegeven uitvoerbare bestand kan worden omgezet; u kunt eventueel argumenten doorgeven die worden gebruikt bij het testen van het hulpprogramma.

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

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

IgnoreAttribute

De IgnoreAttribute slaat onvoorwaardelijk een testklasse of -methode over. Geef desgewenst een reden op om te negeren.

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

Koppeling naar werkitems

Wanneer u tests negeert vanwege bekende problemen, gebruikt WorkItemAttribute of GitHubWorkItemAttribute voor traceerbaarheid:

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

Beste praktijken

1. Parallellisatie verstandig gebruiken: parallellisatie inschakelen voor onafhankelijke tests, maar gebruiken DoNotParallelize voor tests die de status delen.

2. Stel de juiste time-outs in: kies time-outs die normale uitvoering toestaan, maar vastgelopen tests ondervangen. Overweeg trage CI-omgevingen.

3. Voorkeur voor coöperatief annuleren: Gebruik coöperatieve annulering om de overhead van extra taakwikkelaars te voorkomen en uitvoering van time-outtests op de achtergrond te voorkomen. Schakel de MSTEST0045 analyzer in om deze procedure af te dwingen.

4. Genegeerde tests: Verstrek altijd een reden en een work item-referentie bij het negeren van tests.

5. Gebruik herhalingen spaarzaam: pak de hoofdoorzaak van instabiele tests aan in plaats van te vertrouwen op herhalingen.

6. Test besturingssysteemspecifieke code op de juiste manier: gebruik OSCondition dit om platformspecifieke tests alleen uit te voeren waar ze van toepassing zijn.

Zie ook

• MSTest configureren
• Levenscyclus testen
• Schrijftests in MSTest
• MSTEST0001: het kenmerk Parallelliseren gebruiken
• MSTEST0041: kenmerken op basis van voorwaarden gebruiken met testklasse
• MSTEST0043: Gebruik het retry-attribuut op testmethode
• MSTEST0045: Gebruik coöperatieve annulering voor time-out
• MSTEST0059: het kenmerk Parallelliseren juist gebruiken
• MSTEST0061: OsCondition-kenmerk gebruiken in plaats van runtimecontrole