Dela via

Översikt över Microsoft.Testing.Platform

  • Artikel

Microsoft.Testing.Platform är ett enkelt och bärbart alternativ till VSTest för att köra tester i alla kontexter, inklusive CI-pipelines (kontinuerlig integrering), CLI, Visual Studio Test Explorer och VS Code Text Explorer. Microsoft.Testing.Platform är inbäddad direkt i dina testprojekt och det finns inga andra appberoenden, till exempel vstest.console eller dotnet test som behövs för att köra dina tester.

Microsoft.Testing.Platform är öppen källkod. Du hittar Microsoft.Testing.Platform kod i microsoft/testfx- GitHub-lagringsplats.

Grundpelare för Microsoft.Testing.Platform

Den här nya testplattformen bygger på .NET Developer Experience Testing-teamets erfarenhet och syftar till att hantera de utmaningar som har uppstått sedan lanseringen av .NET Core 2016. Det finns en hög kompatibilitetsnivå mellan .NET Framework och .NET Core/.NET, men vissa viktiga funktioner som plugin-systemet och de nya möjliga formfaktorerna för .NET-kompileringar har gjort det komplicerat att utveckla eller helt stödja den nya körningsfunktionen med den aktuella VSTest-plattformen arkitektur.

De viktigaste faktorerna för utvecklingen av den nya testplattformen beskrivs i följande:

  • Determinism: Att se till att samma tester körs i olika kontexter (lokalt, CI) ger samma resultat. Den nya körmiljön förlitar sig inte på reflection eller någon annan dynamisk .NET-körningsfunktion för att koordinera en testkörning.

  • Runtime-transparens: Testkörningen stör inte testramverkets kod, den skapar inte isolerade kontexter som AppDomain eller AssemblyLoadContextoch använder inte reflektions- eller anpassade sammansättningslösare.

  • Kompileringstidsregistrering av tillägg: Tillägg, till exempel testramverk och in-/out-of-process-tillägg, registreras under kompileringstiden för att säkerställa determinism och för att underlätta identifiering av inkonsekvenser.

  • Noll beroenden: Kärnan i plattformen är en enda .NET-sammansättning, Microsoft.Testing.Platform.dll, som inte har några andra beroenden än de körningsmiljöer som stöds.

  • Hostable: Testrutinen kan köras i alla .NET-program. Även om ett konsolprogram ofta används för att köra tester kan du skapa ett testprogram i alla typer av .NET-program. På så sätt kan du köra tester inom särskilda kontexter, till exempel enheter eller webbläsare, där det kan finnas begränsningar.

  • Stöd för alla .NET-formfaktorer: Stöd för aktuella och framtida .NET-formfaktorer, inklusive intern AOT.

  • Effektiv: Hitta rätt balans mellan funktioner och utbyggnadspunkter för att undvika att överbelasta körmiljön med icke-grundläggande kod. Den nya testplattformen är utformad för att "orkestrera" en testkörning i stället för att tillhandahålla implementeringsinformation om hur du gör det.

  • Tillräckligt utbyggbar: Den nya plattformen bygger på utökningspunkter för att möjliggöra maximal anpassning av körningen. Det gör att du kan konfigurera testvärdsprocessen, observera testprocessen och utnyttja information från testramverket inom testvärdsprocessen.

  • Distribuera en enkel modul: Värdbarhetsfunktionen möjliggör en distributionsmodell för en enkel modul, där ett enda kompileringsresultat kan användas för att stödja alla utökningspunkter, både utanför processen och i processen, utan att behöva leverera olika körbara moduler.

Testramverk som stöds

  • MSTest. I MSTest görs stödet för Microsoft.Testing.Platform via MSTest runner.
  • NUnit. I NUnit stöds Microsoft.Testing.Platform via NUnit-testrunner.
  • xUnit.net: I xUnit.net görs stödet för Microsoft.Testing.Platform via xUnit.net testrunner.
  • TUnit: helt konstruerat ovanpå Microsoft.Testing.Platform, mer information finns i TUnit-dokumentationen.

Köra och felsöka tester

Microsoft.Testing.Platform testprojekt byggs som körbara filer som kan köras (eller felsökas) direkt. Det finns ingen extra testkonsol eller extra kommando. Appen avslutas med en annan kod än noll i händelse av fel, vilket är typiskt för de flesta körbara filer. Mer information om kända slutkoder finns i Microsoft.Testing.Platform exit codes.

Tips

Du kan ignorera en specifik slutkod med hjälp av kommandoradsalternativet --ignore-exit-code.

Du kan också ange kommandoradsalternativ som gäller för ett specifikt testprojekt i projektfilen med hjälp av egenskapen TestingPlatformCommandLineArguments MSBuild. Ett vanligt användningsfall är för testprojekt som har alla tester ignorerade, som normalt avslutas med slutkod 8 (testsessionen körde noll tester). I det här scenariot kan du lägga till följande under en PropertyGroup i projektfilen:

<TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>

Viktig

Som standardinställning samlar Microsoft.Testing.Platform in telemetri. För mer information och alternativ för att välja bort, se Microsoft.Testing.Platform telemetri.

Att publicera testprojektet med hjälp av dotnet publish och köra appen direkt är ett annat sätt att köra dina tester. Exekvera till exempel ./Contoso.MyTests.exe. I vissa scenarier är det också möjligt att använda dotnet build för att skapa den körbara filen, men det kan finnas gränsfall att överväga, till exempel Native AOT.

Använd dotnet run

Kommandot dotnet run kan användas för att skapa och köra testprojektet. Det här är det enklaste, men ibland långsammaste, sättet att köra dina tester. Att använda dotnet run är praktiskt när du redigerar och kör tester lokalt, eftersom det säkerställer att testprojektet återskapas när det behövs. dotnet run hittar också projektet automatiskt i den aktuella mappen.

dotnet run --project Contoso.MyTests

Mer information om dotnet runfinns i dotnet run.

Använd dotnet exec

Kommandot dotnet exec eller dotnet används för att köra (eller köra) ett redan byggt testprojekt. Detta är ett alternativ till att köra programmet direkt. dotnet exec kräver sökväg till den byggda testprojektdllen.

dotnet exec Contoso.MyTests.dll

eller

dotnet Contoso.MyTests.dll

Not

Om du anger sökvägen till det körbara testprojektet (*.exe) resulterar det i ett fel:

Error:
  An assembly specified in the application dependencies manifest
  (Contoso.MyTests.deps.json) has already been found but with a different
  file extension:
    package: 'Contoso.MyTests', version: '1.0.0'
    path: 'Contoso.MyTests.dll'
    previously found assembly: 'S:\t\Contoso.MyTests\bin\Debug\net8.0\Contoso.MyTests.exe'

Mer information om dotnet execfinns i dotnet exec.

Använd dotnet test

Microsoft.Testing.Platform erbjuder ett kompatibilitetslager med vstest.console.exe och dotnet test att du kan köra dina tester som tidigare när du aktiverar ett nytt körningsscenario.

dotnet test Contoso.MyTests.dll

Alternativ

I listan nedan beskrivs endast plattformsalternativen. Om du vill se de specifika alternativen för varje tillägg kan du antingen gå till sidan med tilläggsdokumentationen eller använda alternativet --help.

  • @

    Anger namnet på svarsfilen. Svarsfilens namn måste omedelbart följa @-tecknet utan blanksteg mellan @-tecknet och svarsfilens namn.

    Alternativ i en svarsfil tolkas som om de fanns på den platsen på kommandoraden. Varje argument i en svarsfil måste börja och sluta på samma rad. Du kan inte använda omvänt snedstreck () för att sammanfoga linjer. Att använda en svarsfil hjälper till med mycket långa kommandon som kan överskrida terminalgränserna. Du kan kombinera en svarsfil med infogade kommandoradsargument. Till exempel:

    ./TestExecutable.exe @"filter.rsp" --timeout 10s

    där filter.rsp kan ha följande innehåll:

    --filter "A very long filter"

    Eller så kan en enskild rsp-fil användas för att ange både tidsgräns och filter på följande sätt:

    ./TestExecutable.exe @"arguments.rsp"

    --filter "A very long filter"
--timeout 10s

  • --config-file

    Anger en testconfig.json fil.

  • --diagnostic

    Aktiverar diagnostikloggning. Standardloggnivån är Trace. Filen skrivs i utdatakatalogen med följande namnformat, log_[MMddHHssfff].diag.

  • --diagnostic-filelogger-synchronouswrite

    Tvingar den inbyggda filloggaren att synkront skriva loggar. Användbart för scenarier där du inte vill förlora några loggposter (om processen kraschar). Detta gör testkörningen långsammare.

  • --diagnostic-output-directory

    Utdatakatalogen för diagnostikloggningen, om den inte anges, genereras filen i standardkatalogen TestResults.

  • --diagnostic-output-fileprefix

    Prefixet för loggfilens namn. Standardvärdet är "log_".

  • --diagnostic-verbosity

    Definierar verbositetsnivån när växeln --diagnostic används. De tillgängliga värdena är Trace, Debug, Information, Warning, Erroreller Critical.

  • --exit-on-process-exit

    Avsluta testprocessen om den beroende processen går ut. PID måste anges.

  • --help

    Skriver ut en beskrivning av hur du använder kommandot.

  • -ignore-exit-code

    Tillåter att vissa avslutskoder som inte är noll ignoreras och i stället returneras som 0. Mer information finns i Ignorera specifika slutkoder.

  • --info

    Visar avancerad information om .NET-testprogrammet, till exempel:

    • Plattformen.
    • Miljön.
    • Varje registrerad kommandoradsleverantör, till exempel dess name, version, descriptionoch options.
    • Varje registrerat verktyg, till exempel dess command, name, version, descriptionoch alla kommandoradsleverantörer.

    Den här funktionen används för att förstå tillägg som skulle registrera samma kommandoradsalternativ eller ändringar i tillgängliga alternativ mellan flera versioner av ett tillägg (eller plattformen).

  • --list-tests

    Lista tillgängliga tester. Tester kommer inte att köras.

  • --maximum-failed-tests

    Anger det maximala antalet testfel som, när den nås, stoppar testkörningen. Stöd för den här växeln kräver att ramverksförfattare implementerar funktionen IGracefulStopTestExecutionCapability. Slutkoden när du når den mängden testfel är 13. Mer information finns i Microsoft.Testing.Platform utgångskoder.

    Notera

    Den här funktionen är tillgänglig i Microsoft.Testing.Platform från och med version 1.5.

  • --minimum-expected-tests

    Anger det minsta antalet tester som förväntas köras. Som standard förväntas minst ett test köras.

  • --results-directory

    Katalogen där testresultaten ska placeras. Om den angivna katalogen inte finns skapas den. Standardvärdet är TestResults i katalogen som innehåller testprogrammet.

  • --timeout

    En tidsgräns för global testexekvering. Tar ett argument som sträng i formatet <value>[h|m|s] där <value> är flyttal.

MSBuild-integrering

NuGet-paketet Microsoft.Testing.Platform.MSBuild innehåller olika integreringar för Microsoft.Testing.Platform med MSBuild:

  • Stöd för dotnet test. Mer information finns i dotnet-testintegrering.
  • Stöd för ProjectCapability som krävs av Visual Studio och Visual Studio Code Test Explorers.
  • Automatisk generering av startpunkten (Main-metoden).
  • Automatisk generering av konfigurationsfilen.

Anteckning

Den här integreringen fungerar på ett transitivt sätt (ett projekt som refererar till ett annat projekt som refererar till det här paketet fungerar som om det refererar till paketet) och kan inaktiveras via egenskapen IsTestingPlatformApplication MSBuild.

Se även