Microsoft. Tilläggsintegrering

Dessa tillägg överbryggar Microsoft. Testing.Platform (MTP) till de Microsoft.Extensions.* bibliotek som ditt program redan använder, så plattforms- och tilläggskomponenter flödar genom samma infrastruktur som resten av koden. Varje tillägg kräver ytterligare ett NuGet-paket, enligt beskrivningen i varje avsnitt.

Loggningsbrygga

Loggningsbryggan vidarebefordrar Microsoft.Testing.Platform-diagnostikloggar till ILogger, så att plattformens och tilläggens loggar flödar genom samma Microsoft.Extensions.Logging-pipeline som programmet redan använder. Du kan återanvända en befintlig loggningsstack – Konsol, Felsökning, Serilog, Application Insights, OpenTelemetry eller en anpassad ILoggerProvider – utan att skriva en anpassad MTP-loggningsprovider. Det här tillägget kräver Microsoft. Testing.Extensions.Logging NuGet-paketet.

Bryggan vidarebefordrar endast varje meddelande när plattformens diagnostikloggning är aktiverad. När plattformens effektiva loggnivå är None (standardvärdet, såvida du inte skickar --diagnostic), anropas inte konfigurationsdelegaten och ingen loggerfabrik skapas. Filter per kategori som du anger i ILoggingBuilder kan begränsa plattformens effektiva diagnostiknivå, men de kan inte bredda den.

Manuell registrering

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddMicrosoftExtensionsLogging(logging => logging.AddConsole());

Ögonblicksbild av konfiguration

Det experimentella paketet Microsoft.Testing.Extensions.Configuration lägger till en skrivskyddad ögonblicksbild av en programägd IConfiguration i MTP:s konfigurationspipeline.

Registrera konfigurationen innan du skapar testprogrammet:

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddMicrosoftExtensionsConfigurationSnapshot(configuration);

Som standard använder ögonblicksbilden ordning 2. MTP-kommandoradsvärden (order 0) och miljövariabler (ordning 1) har företräde, medan ögonblicksbilden har företräde framför testconfig.json (ordning 3). Ange en annan ordning när applikationen kräver en annan ordningsföljd.

MTP läser snapshoten när BuildAsync bygger konfigurationspipelinen. Senare ändringar och meddelanden om ominläsning vidarebefordras inte. Anroparen behåller ägarskapet för konfigurationen, hierarkiska nycklar behåller standardgränsaren : och registreringen gäller endast för den aktuella processen. Ett aktivt konfigurationsobjekt överförs inte till en separat startad styrenhetsprocess eller testvärdprocess.

Värdintegration

Det experimentella Microsoft.Testing.Extensions.Hosting paketet kör MTP i ett programägt IHost. Värden förblir composition root och ansvarar för sin tjänstleverantör, konfiguration, loggning, OpenTelemetry-leverantörer, livscykel och frigöring av resurser.

För en genererad startpunkt anger du TestingPlatformHostFactory till en fullständigt kvalificerad statisk metod som returnerar en ny, ostartad Task<IHost>:

<TestingPlatformHostFactory>Contoso.Tests.TestHost.CreateHost</TestingPlatformHostFactory>

Ange TestingPlatformOpenTelemetryMode till HostOwned när värden äger OpenTelemetry-leverantörer och testprojektet refererar till Microsoft.Testing.Extensions.OpenTelemetry. Den genererade startpunkten skapar och avslutar värden, bevarar självregistrerade tillägg och kringgår fabriken för kommandoradsalternativen --help och --info.

För en anpassad startpunkt anropar du RunTestingPlatformAsync på värden och registrerar testramverket via dess återanrop. Metoden importerar en konfigurationssnapshot, vidarebefordrar MTP-diagnostik till värdens ILoggerFactory, startar värden före MTP, kopplar värdens och anroparens annullering till MTP, returnerar MTP:s avslutningskod och stoppar värden i ett finally-block. Anroparen avyttrar fortfarande värden.

Håll standardutdata fria från meddelanden från värdstart, avstängning, loggning och exportör eftersom MTP använder det för maskinläsbara lägen som --list-tests json, JSON-RPC serverläge och dotnet test protokollet. Undvik också globala resurser med exklusiv åtkomst i en värdfabrik som används med tillägg för processomstart, eftersom scenarier med återförsök, kraschdumpar eller hangdumpar kan anropa fabriken i styrenhetsprocesser och underordnade processer.