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 (continuous integration), 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 behövs för att köra dina tester.

Microsoft.Testing.Platformär öppen källkod. Du hittar Microsoft.Testing.Platform kod på GitHub-lagringsplatsen microsoft/testfx .

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-plattformsarkitekturen .

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 (lokal, CI) ger samma resultat. Den nya körningen förlitar sig inte på reflektion eller någon annan dynamisk .NET-körningsfunktion för att samordna en testkörning.

  • Körningstransparens: 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örningar som stöds.

  • Värdbar: Testkörningen 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.

  • Performant: Hitta rätt balans mellan funktioner och tilläggspunkter för att undvika att köra körningen 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.

  • Utökningsbar nog: Den nya plattformen bygger på utökningspunkter för att möjliggöra maximal anpassning av körning. Det gör att du kan konfigurera testprocessvärden, observera testprocessen och använda information från testramverket i testvärdprocessen.

  • Distribution av en enskild modul: Värdbarhetsfunktionen möjliggör en distributionsmodell för en enskild modul, där ett enda kompileringsresultat kan användas för att stödja alla utökningspunkter, både processer och processer, utan att behöva skicka olika körbara moduler.

Testramverk som stöds

Köra och felsöka tester

Microsoft.Testing.Platform testprojekt skapas som körbara filer som kan köras (eller kopplas bort) direkt. Det finns inget extra test som kör konsolen eller kommandot. Appen avslutas med en icke-nollavslutskod om det finns ett fel, vilket är typiskt för de flesta körbara filer. Mer information om kända avslutningskoder finns i Microsoft.Testing.Platform exit codes (Slutkoder för Microsoft.Testing.Platform).

Viktigt!

Som standard Microsoft.Testing.Platform samlar telemetri in. Mer information och alternativ för att välja bort finns i Telemetri för Microsoft.Testing.Platform.

Att publicera testprojektet med hjälp av dotnet publish och köra appen direkt är ett annat sätt att köra dina tester. Du kan till exempel köra ./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 tänka på, till exempel intern AOT.

Använda 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. Det är praktiskt att använda dotnet run 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ända dotnet exec

Kommandot dotnet exec eller dotnet används för att köra (eller köra) ett redan byggt testprojekt. Det här ä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

or

dotnet Contoso.MyTests.dll

Kommentar

Om du anger sökvägen till testprojektets körbara (*.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ända dotnet test

Microsoft.Testing.Platform erbjuder ett kompatibilitetslager med vstest.console.exe och dotnet test ser till 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 --help alternativet .

  • --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.

  • --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 kommandoradsprovider, till exempel dess, name, versionoch description options.
  • Varje registrerat verktyg, till exempel dess, command, name, version, descriptionoch alla kommandoradsprovidrar.

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.

  • --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 finns TestResults i katalogen som innehåller testprogrammet.

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 krävs av Visual Studio och Visual Studio Code Test Explorers.
  • Automatisk generering av startpunkten (Main -metoden).
  • Automatisk generering av konfigurationsfilen.

Kommentar

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 IsTestingPlatformApplication egenskapen MSBuild.

Se även