Microsoft. Felsökning av Testing.Platform (MTP)

Den här artikeln innehåller felsökningsvägledning för MTP.

dotnet test Rapporter No test projects were found

När dotnet test körs i MTP-läge mot en lösning eller ett projekt utvärderas projekten och används IsTestingPlatformApplication för att identifiera MTP-testprogram. Testramverk och plattformspaket ställer normalt in den här egenskapen via NuGet MSBuild-importer.

En implicit återställning gör paketimporterna tillgängliga. Dock kan dotnet test i ett containerbygge i flera steg rapportera No test projects were found när båda följande villkor är uppfyllda:

• Teststeget använder --no-restore eller --no-build, vilket innebär --no-restore.
• Teststeget innehåller inte det återställningsgenererade projekttillståndet obj i mappen eller den fullständiga globala paketmappen som återställningssteget använde.

Utan paketimporterna kan IsTestingPlatformApplication utvärderas till ett tomt värde, så dotnet test klassificerar inte projektet som ett MTP-testprogram. Det här problemet är inte specifikt för MSTest.

Lös problemet genom att använda någon av följande metoder:

• Återställ projektet i testfasen innan du kör dotnet test.
• Kopiera eller bevara den återställningsgenererade obj mappen och den fullständiga globala paketmappen från återställningsfasen. Mappen obj innehåller filer som project.assets.json, *.nuget.g.propsoch *.nuget.g.targets. Om du anger NUGET_PACKAGES eller RestorePackagesPathbevarar du mappen globala paket på den konfigurerade platsen.
• Om teststeget innehåller redan byggda testprogram men inte tillståndet för projektåterställning använder du dotnet test --test-modules <EXPRESSION>. Det här alternativet väljer inbyggda testmoduler utan projektutvärdering.

Utgångskoder

MTP använder kända slutkoder för att kommunicera testfel eller appfel. Slutkoderna börjar vid 0 och är icke-negativa.

Slutkod	Detaljer
0	Slutkoden 0 indikerar att det lyckades. Alla tester som valdes att köra kördes till slutförande och det fanns inga fel.
1	Slutkoden 1 anger okända fel och fungerar som en catch all. Om du vill hitta ytterligare felinformation och mer detaljer tittar du i utdata.
2	En slutkod 2 för används för att indikera att det inträffade minst ett testfel.
3	Slutkoden 3 anger att testsessionen avbröts. En session kan avbrytas med Ctrl+C som exempel.
4	Slutkoden 4 anger att konfigurationen av använda tillägg är ogiltig och att testsessionen inte kan köras.
5	Slutkoden 5 anger att kommandoradsargumenten som skickades till testappen var ogiltiga.
6 (används inte längre)	Slutkoden 6 produceras inte längre av plattformen. Tidigare angavs att testsessionen använde en funktion som inte implementerades.
7	Slutkoden 7 anger att en testsession inte kunde slutföras och troligen kraschade. Det är möjligt att detta orsakades av en testsession som kördes via en testkontrollants tilläggspunkt.
8	Slutkoden 8 anger att testsessionen inte identifierade några tester eller att varje valt test hoppades över under strikt --zero-tests-policy.
9	Slutkoden 9 anger att körningen körde färre tester än vad ett explicit --minimum-expected-tests värde kräver, inklusive noll tester.
10	Slutkoden 10 anger att testkortet Testing.Platform Test Framework, MSTest, NUnit eller xUnit inte kunde köra tester av en infrastrukturorsak som inte är relaterad till själva testet. Ett exempel är att det inte går att skapa en fixtur som krävs av tester.
11	Slutkoden 11 anger att testprocessen avslutas om den beroende processen avslutas.
12	Slutkoden 12 anger att testsessionen inte kunde köras eftersom klienten inte stöder någon av de protokollversioner som stöds.
13	Slutkoden 13 anger att testsessionen stoppades eftersom det angivna antalet maximalt misslyckade tester har uppnåtts med --maximum-failed-tests kommandoradsalternativet. Mer information finns i avsnittet Alternativ i referensen för MTP CLI-alternativ
14	Slutkoden 14 anger att en kompatibel täckningsinsamlare publicerade en utvärdering av tröskelvärdet för misslyckad täckning.

Ett explicit --minimum-expected-tests värde ersätter --zero-tests-policy. Utan minsta alternativ fortsätter strikt nolltesthantering att använda slutkoden 8. Returkoderna 8 och 9 hålls åtskilda så att ett minimikrav som inte uppfyllts inte förväxlas med en modul där inga tester kördes.

Information om hur du aktiverar utförlig loggning och felsökning av problem finns i Diagnostikloggning.

Noll tester i en körning med flera moduler

När dotnet test flera testmoduler körs är slutkoden 8 en signal per modul, medan nolltestutfallet för hela körningen bestäms en gång från de aggregerade resultaten. En enda tom modul gör därför inte att hela körningen misslyckas, även om modulen behåller sitt Exit code: 8 diagnostikmeddelande i utdata. När du inte anger ett globalt minimum behandlas en helt överhoppad hel körning som en nolltestkörning oavsett värdet per modul --zero-tests-policy . Mer information finns i Minimum för helkörning och per modul.

Anmärkning

Den här nolltestutfallet för hela körningen kräver .NET 11 SDK eller en senare version.

Ignorera specifika slutkoder

MTP är utformat för att vara strikt som standard men möjliggör konfigurerbarhet. Därför är det möjligt för användare att bestämma vilka slutkoder som ska ignoreras (en slutkod 0 för returneras i stället för den ursprungliga slutkoden).

Om du vill ignorera specifika slutkoder använder du --ignore-exit-code kommandoradsalternativet TESTINGPLATFORM_EXITCODE_IGNORE eller miljövariabeln. Det giltiga format som accepteras är en semikolonavgränsad lista med slutkoder att ignorera (till exempel --ignore-exit-code 2;3;8). Ett vanligt scenario är att tänka på att testfel inte bör resultera i en icke-nollavslutskod (vilket motsvarar att ignorera slutkod 2).

Diagnostisk loggning

Plattformen tillhandahåller inbyggd diagnostikloggning som hjälper dig att felsöka testkörning. Du kan aktivera diagnostikloggning via kommandoradsalternativ eller miljövariabler.

Alternativ för kommandoraden

Följande plattformsalternativ ge användbar information för felsökning av testappar:

• --info
• --diagnostic
• --diagnostic-synchronous-write
• --diagnostic-verbosity
• --diagnostic-file-prefix
• --diagnostic-output-directory

Miljövariabler

Du kan också aktivera diagnostikloggarna med hjälp av miljövariablerna:

Miljövariabelnamn	Description
TESTINGPLATFORM_DIAGNOSTIC	Om värdet är inställt på 1aktiverar du diagnostikloggningen.
TESTINGPLATFORM_DIAGNOSTIC_VERBOSITY	Definierar verbositetsnivån. De tillgängliga värdena är Trace, Debug, Information, Warning, Erroreller Critical.
TESTINGPLATFORM_DIAGNOSTIC_OUTPUT_DIRECTORY	Utdatakatalogen för diagnostikloggningen, om den inte anges, genereras filen i standardkatalogen TestResults.
TESTINGPLATFORM_DIAGNOSTIC_FILE_PREFIX	Prefixet för loggfilens namn. Standardvärdet genererar <asm>_<tfm>_<arch>_<timestamp>.diag. Tillgänglig i MTP från och med version 2.3.0; det äldre namnet TESTINGPLATFORM_DIAGNOSTIC_OUTPUT_FILEPREFIX respekteras fortfarande för bakåtkompatibilitet.
TESTINGPLATFORM_DIAGNOSTIC_SYNCHRONOUS_WRITE	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. Tillgänglig i MTP från och med version 2.3.0; det äldre namnet TESTINGPLATFORM_DIAGNOSTIC_FILELOGGER_SYNCHRONOUSWRITE respekteras fortfarande för bakåtkompatibilitet.

Anmärkning

Miljövariabler har företräde framför kommandoradsargumenten.

MTP skriver en diagnostikfil för varje testkälla. Om två filer får samma tidsstämpel lägger MTP till ett process- och räknarsuffix i stället för att skriva över en befintlig fil.

Lösa konfigurationsfel

Microsoft.Testing.Platform.MSBuild

Följande är vanliga konfigurationsfel relaterade till Microsoft.Testing.Platform.MSBuild.

fel CS8892: Metoden "TestingPlatformEntryPoint.Main(string[])" används inte som startpunkt eftersom en synkron startpunkt "Program.Main(string[])" hittades

Att manuellt definiera en startpunkt (Main) i ett testprojekt eller referera till ett testprojekt från ett program som redan har en startpunkt resulterar i en konflikt med startpunkten som genereras av MTP. Undvik det här problemet genom att utföra något av följande steg:

• Ta bort din manuellt definierade startpunkt, vanligtvis Main metod i Program.csoch låt testplattformen generera en åt dig.

• Inaktivera genereringen av startpunkten genom att ange egenskapen <GenerateTestingPlatformEntryPoint>false</GenerateTestingPlatformEntryPoint> MSBuild.

• Inaktivera det transitiva beroendet till Microsoft.Testing.Platform.MSBuild helt genom att ange egenskapen <IsTestingPlatformApplication>false</IsTestingPlatformApplication> MSBuild i projektet som refererar till ett testprojekt. Detta behövs när du refererar till ett testprojekt från ett icke-testprojekt, till exempel en konsolapp som refererar till ett testprogram.

Genererat kodnamnområde står i konflikt med en referenstyp

Microsoft.Testing.Platform.MSBuild genererar typerna SelfRegisteredExtensions och TestingPlatformEntryPoint i projektets $(RootNamespace). Som standard RootNamespace matchar projektnamnet, som kan kollidera med en typ av samma fullständigt kvalificerade namn som exponeras av en refererad sammansättning.

Ett projekt med namnet System.Security.Cryptography.ProtectedData.Tests genererar till exempel kod i System.Security.Cryptography.ProtectedData namnområdet. Om projektet även refererar till System.Security.Cryptography.ProtectedData NuGet-paketet, som innehåller en offentlig ProtectedData typ under System.Security.Cryptography namnområdet, kan kompilatorn inte längre skilja mellan det genererade namnområdet och den refererade typen och genererar fel som CS0118 ("ProtectedData" är ett namnområde men används som en typ).

För att lösa konflikten åsidosätter du RootNamespace i testprojektet till ett värde som inte kolliderar med någon refererad typ:

<PropertyGroup>
  <RootNamespace>System.Security.Cryptography.ProtectedDataTests</RootNamespace>
</PropertyGroup>

Du kan också rensa RootNamespace helt (<RootNamespace />), i vilket fall de genererade typerna genereras till det globala namnområdet.

Microsoft.Testing.Extensions.Fakes

Förfalskningsfel Det gick inte att lösa profilerarsökvägen från COR_PROFILER_PATH och COR_PROFILER miljövariabler

Det här felet kan inträffa om inte alla förfalskningssammansättningar finns i mappen bin.

• Kontrollera att projektet antingen använder MSTest.SDK eller refererar till Microsoft.Testing.Extensions.Fakes.
• För .NET Framework-projekt bör du undvika att ange <PlatformTarget>AnyCPU</PlatformTarget> eftersom detta resulterar i att NuGet inte kopierar alla filer till mappen bin.

Okänt kommandoradsalternativ för tillägg

Ett tilläggsspecifikt kommandoradsalternativ kan misslyckas med slutkod 5 när ett testprogram inte registrerar paketet som tillhandahåller alternativet. --report-trx kräver till exempel Microsoft.Testing.Extensions.TrxReport, antingen som en direkt paketreferens eller genom en test-SDK-konfiguration eller profil som innehåller paketet. MTP-kärnan innehåller inte rapport, kodtäckning, dump, återförsök eller andra tilläggsalternativ.

Kör testprogrammet med --helpeller kör dotnet test --help i MTP-läge för att bekräfta att alternativet är tillgängligt. Om alternativet saknas lägger du till dess tilläggspaket eller aktiverar tillägget via test-SDK:t. Se Tilläggsalternativ efter scenario för att hitta det nödvändiga paketet.

Samma fel uppstår när en lösning innehåller projekt som använder olika testramverk (till exempel MSTest och xUnit.net) eller olika uppsättningar med tillägg (till exempel endast vissa projektreferenser Microsoft.Testing.Extensions.HangDump). Alternativet är giltigt för ett projekt men okänt av ett annat.

Lös problemet genom att använda TestingPlatformCommandLineArguments egenskapen MSBuild med villkor för att dirigera argument till rätt projekt. Detaljerade anvisningar finns i Lösningar med blandade testramverk eller tillägg.