Eseguire la migrazione da VSTest a Microsoft.Testing.Platform

Questo articolo illustra come eseguire la migrazione da VSTest a Microsoft.Testing.Platform.

Questo articolo è incentrato sui passaggi di migrazione e sul mapping degli argomenti.

Se è ancora necessario scegliere una piattaforma, iniziare con Panoramica delle piattaforme di test.

Se è necessario un comportamento dettagliato delle dotnet test modalità, vedere Test con dotnet test.

Se hai bisogno di un elenco unico delle opzioni della riga di comando della piattaforma e delle estensioni, consulta il riferimento alle opzioni CLI di Microsoft.Testing.Platform.

Acconsentire esplicitamente all'uso di Microsoft.Testing.Platform

Il primo passaggio della migrazione consiste nell'acconsentire esplicitamente all'uso di Microsoft.Testing.Platform.

Per tutti i framework di test, aggiungere <OutputType>Exe</OutputType> a tutti i progetti di test nella soluzione. Successivamente, seguire le indicazioni specifiche del framework.

MSTest

Microsoft.Testing.Platform è supportato da MSTest a partire dalla versione 3.2.0. È tuttavia consigliabile eseguire l'aggiornamento alla versione MSTest più recente disponibile.

Per aderire, aggiungere <EnableMSTestRunner>true</EnableMSTestRunner> sotto un PropertyGroup nel file Directory.Build.props.

NUnit

Microsoft.Testing.Platform è supportato da NUnit3TestAdapter a partire dalla versione 5.0.0.

Per aderire, aggiungere <EnableNUnitRunner>true</EnableNUnitRunner> sotto un PropertyGroup nel file Directory.Build.props.

xUnit.net

Microsoft.Testing.Platform è supportato a partire da xunit.v3.

Per aderire, aggiungere <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> sotto un PropertyGroup nel file Directory.Build.props.

dotnet test

Acconsentire esplicitamente a .NET 9 SDK e versioni precedenti

In .NET 9 SDK e versioni precedenti non è disponibile alcun supporto nativo per Microsoft.Testing.Platform per dotnet test. Il supporto è basato sull'infrastruttura VSTest. Per usarlo, aggiungere <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> sotto un PropertyGroup in un file Directory.Build.props.

Acconsentire esplicitamente a .NET 10 SDK e versioni successive

A partire da .NET 10 SDK, è disponibile il supporto nativo per Microsoft.Testing.Platform. Per usarlo, è necessario specificare il test runner come Microsoft.Testing.Platform in global.json:

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Aggiornare dotnet test le chiamate

Le opzioni della riga di comando di dotnet test sono suddivise in due categorie: argomenti correlati alla compilazione e quelli correlati ai test.

Gli argomenti correlati alla compilazione sono irrilevanti per la piattaforma di test e, di conseguenza, non devono essere aggiornati per la nuova piattaforma. Gli argomenti relativi alla build sono elencati qui:

• -a|--arch <ARCHITECTURE>
• --artifacts-path <ARTIFACTS_DIR>
• -c|--configuration <CONFIGURATION>
• -f|--framework <FRAMEWORK>
• -e|--environment <NAME="VALUE">
• --interactive
• --no-build
• --nologo
• --no-restore
• -o|--output <OUTPUT_DIRECTORY>
• --os <OS>
• -r|--runtime <RUNTIME_IDENTIFIER>
• -v|--verbosity <LEVEL>

Gli argomenti correlati al test sono specifici di VSTest e quindi devono essere trasformati in modo che corrispondano alla nuova piattaforma. La tabella seguente illustra il mapping tra gli argomenti VSTest e la nuova piattaforma:

--collect

--collect è un punto di estendibilità generale in VSTest per qualsiasi agente di raccolta dati. Il modello di estendibilità di Microsoft.Testing.Platform è diverso e non esiste tale argomento centralizzato da usare da tutti gli agenti di raccolta dati. Con Microsoft.Testing.Platform, ogni agente di raccolta dati può aggiungere una propria opzione della riga di comando. Ad esempio, l'esecuzione di Microsoft CodeCoverage tramite VSTest potrebbe essere simile alla seguente:

dotnet test --collect "Code Coverage;Format=cobertura"

Con Microsoft.Testing.Platform, diventa:

dotnet test --coverage --coverage-output-format cobertura

--filter

--filter è il filtro basato su VSTest.

MSTest e NUnit supportano lo stesso formato di filtro anche durante l'esecuzione con Microsoft.Testing.Platform.

xUnit.net, non supporta lo stesso formato di filtro durante l'esecuzione con Microsoft.Testing.Platform. È necessario eseguire la migrazione dal filtro basato su VSTest al nuovo supporto del filtro in xunit.v3, disponibile usando le opzioni della riga di comando seguenti.

xUnit.net opzioni specifiche:

• --filter-class
• --filter-not-class
• --filter-method
• --filter-not-method
• --filter-namespace
• --filter-not-namespace
• --filter-trait
• --filter-not-trait
• --filter-query

Per altre informazioni, vedere la documentazione di Microsoft.Testing.Platform per xUnit.net e Query Filter Language for xUnit.net.

--logger

Ciò che si chiama solitamente "logger" in VSTest è chiamato "reporter" in Microsoft.Testing.Platform. In Microsoft.Testing.Platform la registrazione viene eseguita in modo esplicito solo a scopo di diagnosi.

Analogamente a --collect, --logger è un punto di estendibilità generale in VSTest per qualsiasi logger (o, nel contesto di Microsoft.Testing.Platform, qualsiasi reporter). Ogni reporter di Microsoft.Testing.Platform ha la libertà di aggiungere una propria opzione della riga di comando e, pertanto, non esiste un'opzione della riga di comando centralizzata come quella di VSTest --logger.

Uno dei logger VSTest usati molto comunemente è il logger TRX. Questo logger viene in genere chiamato come segue:

dotnet test --logger trx

Con Microsoft.Testing.Platform, il comando diventa:

dotnet test --report-trx

--settings

VSTest --settings viene usato per specificare un file RunSettings per l'esecuzione del test. RunSettings non è supportato dal core Microsoft.Testing.Platform ed è stato sostituito da un file di configurazione più moderno testconfig.json . Tuttavia, MSTest e NUnit supportano ancora runSettings precedenti durante l'esecuzione di Microsoft.Testing.Platform ed --settings è ancora supportato.

vstest.console.exe

Se si usa vstest.console.exe direttamente, è consigliabile sostituirlo con il dotnet test comando .

Esploratore di test

Quando si usa Visual Studio o Esplora test di Visual Studio Code, potrebbe essere necessario abilitare il supporto per Microsoft.Testing.Platform.

Visual Studio

Esplora Test di Visual Studio supporta Microsoft.Testing.Platform a partire dalla versione 17.14. Se si usa una versione precedente, potrebbe essere necessario aggiornare Visual Studio alla versione più recente.

Visual Studio Code

Visual Studio Code con C# DevKit supporta Microsoft.Testing.Platform.

Azure DevOps

Quando si usano le attività di Azure DevOps, potrebbe essere necessario aggiornare la pipeline per usare Microsoft.Testing.Platform, a seconda dell'attività usata.

Attività VSTest

Se si usa l'attività VSTest in Azure DevOps, è possibile sostituirla con l'attività .NET Core.

Attività CLI di .NET Core

• Se hai passato un arguments personalizzato all'attività, segui le stesse indicazioni per la migrazione di dotnet test.

• Se si usa l'attività DotNetCoreCLI senza acconsentire esplicitamente all'esperienza nativa di Microsoft.Testing.Platform per .NET 10 SDK e versioni successive tramite global.json file, è necessario impostare l'attività arguments in modo che punti correttamente alla directory dei risultati a cui punta, nonché al report TRX richiesto. Per esempio:

  - task: DotNetCoreCLI@2
    displayName: Run unit tests
    inputs:
      command: 'test'
      arguments: '-- --report-trx --results-directory $(Agent.TempDirectory)'
  

Differenze comportamentali tra VSTest e Microsoft.Testing.Platform

Esecuzione di nessun test

Se un assembly di test ha eseguito zero test, VSTest tollera che e termina con esito positivo. Tuttavia, Microsoft.Testing.Platform ha esito negativo con codice di uscita 8. Esistono diversi modi per risolvere questo problema:

• Passa --ignore-exit-code 8 durante l'esecuzione dei test.

• Se si vuole ignorare il codice di uscita per un progetto di test specifico, aggiungere quanto segue nel file di progetto:

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

• Usare la TESTINGPLATFORM_EXITCODE_IGNORE variabile di ambiente.

Conservazione di Console.InputEncoding

Se si eseguono i test in una console in cui la tabella codici è stata modificata in modo esplicito(ad esempio, in Azure DevOps, la tabella codici è impostata su 65001 che corrisponde a UTF8), il comportamento può essere diverso tra VSTest e Microsoft.Testing.Platform.

• Con Microsoft.Testing.Platform, la codifica viene sempre preservata.
• Con VSTest non in esecuzione in modalità di isolamento (il comportamento predefinito di vstest.console), tale codifica viene mantenuta, simile a Microsoft.Testing.Platform.
• Con VSTest in esecuzione in modalità di isolamento (comportamento predefinito di dotnet test), la codifica non viene mantenuta nel testhost, ovvero il processo che esegue i test.

Se si dispone di un test che avvia ancora un altro processo figlio e ne reindirizza l'output standard, è possibile che si verifichino problemi se si applicano tutte le operazioni seguenti:

• La tabella codici della console è impostata su 65001 (UTF8). Questo può essere il caso nei sistemi di integrazione continua, ma in genere non in ambiente locale. Per ottenere un comportamento locale simile a in CI, eseguire chcp 65001 prima di eseguire i test.
• Il processo figlio viene avviato con una codifica diversa da UTF-8. Ciò può verificarsi anche se il tuo test imposta CreateNoWindow = true.

Ciò è particolarmente problematico quando il processo figlio non si aspetta di ricevere il byte BOM UTF8 (Byte-Order-Mark), che potrebbe incontrare nello scenario precedente su .NET Framework.

Poiché è probabile che questa differenza di comportamento sia problematica specificamente per il byte bom, una soluzione alternativa consiste nell'impostare InputEncoding durante l'inizializzazione dell'assembly su UTF8 senza BOM:

Console.InputEncoding = new UTF8Encoding(encoderShouldEmitUTF8Identifier: false);

Una soluzione alternativa consiste nel non utilizzare CreateNoWindow = true per i processi figlio che reindirizzano l'input standard.