Testkörning och kontroll i MSTest

MSTest tillhandahåller attribut för att styra hur tester körs, inklusive parallellisering, trådningsmodeller, tidsgränser, återförsök och villkorsstyrd körning baserat på plattform eller miljö.

Trådningsegenskaper

Trådattribut styr vilka testmetoder för trådmodeller som används. Dessa attribut är viktiga när du testar COM-komponenter, gränssnittselement eller kod med specifika trådkrav.

STATestClassAttribute

Kör STATestClassAttribute alla testmetoder i en klass (inklusive ClassInitialize och ClassCleanup) i en enkeltrådad lägenhet (STA). Använd det här attributet när du testar COM-objekt som kräver STA.

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

STATestMethodAttribute

Kör STATestMethodAttribute en specifik testmetod i en entrådad lägenhet. Använd det här attributet för enskilda tester som behöver STA medan andra tester i klassen inte gör det.

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

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

Bevara STA-kontext för asynkrona fortsättningar

Från och med MSTest 4.1 inkluderar STATestMethodAttribute en egenskap UseSTASynchronizationContext som säkerställer att asynkrona fortsättningar körs på samma STA-tråd. När det är aktiverat skapar attributet en anpassad SynchronizationContext som publicerar fortsättningar tillbaka till STA-tråden, vilket är viktigt för testning av gränssnittskomponenter som kräver STA-trådning under hela asynkrona åtgärder.

[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

Attributet UITestMethod schemalägger testkörning i användargränssnittstråden. Det här attributet är utformat för att testa UWP- och WinUI-program som kräver UI-trådåtkomst.

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

Parallelliseringsattribut

Parallelliseringsattribut styr om och hur tester körs samtidigt, vilket förbättrar testkörningstiden.

ParallelizeAttribute

Som standard kör MSTest tester sekventiellt. Attributet ParallelizeAttribute på sammansättningsnivå möjliggör parallell testkörning.

using Microsoft.VisualStudio.TestTools.UnitTesting;

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

Parallelliseringsomfång

Arbetartrådar

Egenskapen Workers anger det maximala antalet trådar för parallell körning:

• 0 (standard): Använd antalet logiska processorer på datorn
• Valfritt positivt heltal: Använd det angivna antalet trådar

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

DoNotParallelizeAttribute

DoNotParallelizeAttribute Förhindrar parallell körning för specifika sammansättningar, klasser eller metoder. Använd det här attributet när tester delar tillstånd eller resurser som inte kan nås på ett säkert sätt samtidigt.

[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

Använd [ResourceLock] för att serialisera endast tester som har åtkomst till samma namngivna resurs. Till skillnad från [DoNotParallelize]blockerar inte ett resurslås tester som använder orelaterade resurser. Standardläget ReadWrite är exklusivt, medan flera tester som begär ResourceAccessMode.Read samma resurs kan köras tillsammans.

private const string Database = "integration-database";

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

För processomfattande tillstånd använder du konstanterna i WellKnownResources: CurrentDirectory, EnvironmentVariablesoch Console. Låsnamn använder ordningstal, skiftlägeskänslig likhet och samordnar tester endast inom en testkälla eller sammansättning. De samordnar inte tester från separata sammansättningar, processer eller datorer, inte ens när dessa tester använder samma nyckel.

Låsomfånget följer det konfigurerade parallelliseringsomfånget:

• Med ClassLevelkombinerar MSTest varje lås som deklarerats på klassen och dess metoder och har sedan det starkaste läget för hela klassens livscykel.
• Med MethodLevelhämtar MSTest lås för varje test, inklusive testinitiering och rensning.
• När parallellisering inaktiveras har resurslås ingen effekt.

Om ett test också använder [DoNotParallelize], [DoNotParallelize] har företräde och MSTest ignorerar dess resurslås. Ett test som väntar på ett utmanat lås upptar en arbetare, så hård låskonkurrens kan fortfarande minska dataflödet.

Testa beroenden

Används [DependsOn] för integrerings- eller slutpunkt-till-slutpunkt-tester som måste köras efter andra tester. Beroenden utgör ett riktat acykliskt diagram, så oberoende grenar kan fortfarande köras parallellt.

[TestMethod]
public void CreateCart() { }

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

Använd flera [DependsOn] attribut för fan-in eller tillämpa attributet på flera tester för utloggning. Du kan referera till en metod i samma klass, varje test i en annan klass eller en metod i en annan klass. Tillämpa [DependsOn] på en testklass för att ge varje test i den klassen beroendet. När ett beroende är avsett för ett datadrivet test väntar MSTest på alla sina datarader.

Som standard hoppar ett misslyckat krav över dess beroenden och hoppa över sprids. MSTest utvärderar ProceedOnFailure per beroende test, inte per kant. Om du vill köra ett beroende efter misslyckade krav anger du ProceedOnFailure = true för varje [DependsOn] deklaration för testet. En deklaration kvar som standard gör att MSTest hoppar över beroendet. MSTest rapporterar beroendecykler före körning och misslyckas med testerna i cykeln. Om ett beroende inte ingår i den valda körningen varnar MSTest och ignorerar den saknade gränsen så att filter och enkla testkörningar fortfarande fungerar.

Med Microsoft. Testing.Platform kan du även deklarera beroenden under mstest.execution.dependencies i testconfig.json:

• Använd chains för raka sekvenser.
• Använd nodes för fan-in, fan-out och proceedOnFailure.

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

Referera till ett test med dess Namespace.Class.Method namn eller referera till varje test i en klass med Namespace.Class.*. MSTest sammanfogar konfigurationsberoenden med beroenden som deklarerats via attribut.

Formuläret testconfig.json fungerar bara med Microsoft. Testing.Platform. Attributet [DependsOn] fungerar med båda Microsoft. Testing.Platform och VSTest. Aktivera MSTEST0078 för validering av byggtid.

Timeout-attribut

Timeout-attribut hindrar tester från att köras på obestämd tid och hjälper till att identifiera prestandaproblem.

TimeoutAttribute

TimeoutAttribute Anger den maximala tid (i millisekunder) som en test- eller fixturmetod kan köra. Om körningen överskrider den här tiden misslyckas testet.

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

Tillämpa timeout på fixeringsmetoder

Du kan också använda tidsgränser för initierings- och rensningsmetoder.

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

Kooperativ avbokning

Som standard omsluter MSTest varje tidsinställda testmetod i en separat uppgift eller tråd. När tidsgränsen nås slutar ramverket att observera testet, men den underliggande aktiviteten fortsätter att köras i bakgrunden. Det här beteendet kan orsaka problem:

• Testmetoden fortsätter att komma åt resurser och mutera tillstånd även efter timeout.
• Bakgrundskörning kan leda till konkurrensförhållanden som påverkar efterföljande tester.
• Varje tidsstyrd metod medför ytterligare belastning från uppgifts-/trådinkapslingen.

Från och med MSTest 3.6 använder du CooperativeCancellation egenskapen för att undvika dessa problem. I samarbetsläge omsluter MSTest inte testet i en extra uppgift. När tidsgränsen nås signalerar ramverket i stället annulleringstoken. Din testkod ansvarar för att kontrollera token regelbundet och avsluta på ett smidigt sätt.

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

Fördelar med kooperativ annullering:

• Lägre prestandaomkostnader (ingen extra uppgift/trådomslutning per test).
• Renare resursrensning eftersom koden uttryckligen hanterar annullering.
• Överensstämmer med standardmönster för .NET-annullering.
• Deterministiskt beteende genom att undvika konkurrensförhållanden mellan testkod och obemärkt bakgrundskörning.

Försök med attribut igen

Omförsöksattribut hjälper till att hantera flagnande tester genom att automatiskt köra misslyckade tester igen.

RetryAttribute

Den RetryAttribute, som introducerades i MSTest 3.8, återförsöker automatiskt testmetoder som misslyckas eller går ut på tid. Konfigurera maximalt antal försök, fördröjning mellan försök och backoff-strategi.

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

Konfigurationsalternativ

Anpassade återförsöksimplementeringar

Från och med MSTest 3.8 skapar du anpassad logik för återförsök genom att ärva från RetryBaseAttribute:

public class CustomRetryAttribute : RetryBaseAttribute
{
    private readonly int _maxRetries;

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

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

Attribut för villkorsstyrd körning

Attribut för villkorsstyrd körning styr om tester körs baserat på specifika villkor som operativsystem eller CI-miljö.

ConditionBaseAttribute

ConditionBaseAttribute är den abstrakta basklassen för villkorsstyrd körning. MSTest innehåller flera inbyggda implementeringar.

OSConditionAttribute

Beroende på operativsystemet kör eller hoppar OSConditionAttribute över tester. Använd flaggorna OperatingSystems för att ange vilka operativsystem som ska tillämpas.

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

Operativsystem som stöds

Kombinera operativsystem med bitvis ELLER-operatorn (|).

CIConditionAttribute

Kör CIConditionAttribute eller hoppar över tester baserat på om de körs i en kontinuerlig integrationsmiljö.

[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

, MemberConditionAttributesom introducerades i MSTest 4.3, kör eller hoppar över en testklass eller testmetod baserat på värdet för en eller flera statiska bool medlemmar. Varje medlem refereras till av sin deklareringstyp och namn och måste vara public static, return bool, och (för metoder) vara parameterlösa. När flera medlemmar anges kombineras de med ett logiskt AND. Använd ConditionMode för att invertera villkoret.

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

, ArchitectureConditionAttributesom introducerades i MSTest 4.3, kör eller hoppar över tester baserat på processarkitekturen. Använd TestArchitectures flagguppräkningen för att ange vilka arkitekturer som gäller.

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

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

ExecutableConditionAttribute

, ExecutableConditionAttributesom introducerades i MSTest 4.3, kör eller hoppar över tester baserat på om ett externt verktyg är tillgängligt. Testet körs endast när den angivna körbara filen kan hittas; du kan valfritt ange argument som används när verktyget undersöks.

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

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

IgnoreAttribute

Utan förbehåll hoppar IgnoreAttribute över en testklass eller metod. Du kan också ange en orsak till att ignorera.

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

Länka till arbetsobjekt

När du ignorerar tester på grund av kända problem kan du använda WorkItemAttribute eller GitHubWorkItemAttribute för spårbarhet.

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

Metodtips

1. Använd parallellisering klokt: Aktivera parallellisering för oberoende tester, men använd DoNotParallelize för tester som delar tillstånd.

2. Ange lämpliga tidsgränser: Välj tidsgränser som tillåter normal körning men fångar upp fastnade tester. Överväg långsamma CI-miljöer.

3. Föredrar kooperativ annullering: Använd kooperativ annullering för att undvika extra aktivitetsomslutningar och förhindra bakgrundskörning av tidsgränstester. Aktivera MSTEST0045-analysatorn för att tillämpa den här metoden.

4. Dokumentera ignorerade tester: Ange alltid en orsak och en referens till arbetsobjekt när du ignorerar tester.

5. Använd återförsök sparsamt: Åtgärda rotorsaken till flagnande tester i stället för att förlita sig på återförsök.

6. Testa OS-specifik kod på lämpligt sätt: Använd OSCondition för att köra plattformsspecifika tester endast där de är tillämpliga.

Se även

• Konfigurera MSTest
• Testlivscykel
• Skriva tester i MSTest
• MSTEST0001: Använd attributet Parallelize
• MSTEST0041: Använda villkorsbaserade attribut med testklass
• MSTEST0043: Använd återförsöksattribut på testmetoden
• MSTEST0045: Använd kooperativ annullering vid tidsgränsen
• MSTEST0059: Använd attributet Parallelize korrekt
• MSTEST0061: Använd OSCondition-attribut i stället för körningskontroll