Eseguire la migrazione da VSTest a Microsoft. Testing.Platform (MTP)

Questo articolo illustra come eseguire la migrazione da VSTest a MTP.

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 è necessario un elenco unico delle opzioni della riga di comando per la piattaforma e l'estensione, vedere il riferimento alle opzioni CLI MTP.

Acconsentire esplicitamente all'uso di MTP

Il primo passaggio della migrazione consiste nel acconsentire esplicitamente all'uso di MTP.

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

MTP è 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.

Annotazioni

Quando si usa MSTest.Sdk, MTP viene usato per impostazione predefinita, a meno che non <UseVSTest>true</UseVSTest> venga specificato.

NUnit

MTP è 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

MTP è 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 esiste alcun supporto native per MTP per dotnet test. Il supporto è basato sull'infrastruttura VSTest. Per usarlo, aggiungere <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> sotto un PropertyGroup in un file Directory.Build.props.

Importante

Quando si esegue il supporto MTP in questa modalità, è necessario aggiungere -- per separare gli dotnet test argomenti dai nuovi argomenti della piattaforma. Ad esempio: dotnet test --no-build -- --list-tests.

Acconsentire esplicitamente a .NET 10 SDK e versioni successive

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

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

Importante

In questa modalità, l'extra -- non viene più usato.

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:

Argomento VSTest Nuovo argomento della piattaforma
--test-adapter-path <ADAPTER_PATH> Non rilevante per MTP
--blame Non rilevante per MTP
--blame-crash --crashdump (richiede l'estensione di dump di arresto anomalo del sistema)
--blame-crash-dump-type <DUMP_TYPE> --crashdump-type (richiede l'estensione di dump di arresto anomalo del sistema)
--blame-crash-collect-always Non supportato
--blame-hang --hangdump (richiede l'estensione Hang dump)
--blame-hang-dump-type <DUMP_TYPE> --hangdump-type (richiede l'estensione Hang dump)
--blame-hang-timeout <TIMESPAN> --hangdump-timeout (richiede l'estensione Hang dump)
--collect <DATA_COLLECTOR_NAME> Dipende dall'agente di raccolta dati
-d\|--diag <LOG_FILE> --diagnostic
--filter <EXPRESSION> Dipende dal framework di test selezionato
-l\|--logger <LOGGER> Dipende dal logger
--results-directory <RESULTS_DIR> --results-directory <RESULTS_DIR>
-s\|--settings <SETTINGS_FILE> Dipende dal framework di test selezionato
-t\|--list-tests --list-tests
-- <RunSettings arguments> --test-parameter (fornito da VSTestBridge)

--collect

--collect è un punto di estendibilità generale in VSTest per qualsiasi agente di raccolta dati. Il modello di estendibilità di MTP è diverso e non esiste un argomento centralizzato di questo tipo da usare da tutti gli agenti di raccolta dati. Con MTP, 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 MTP, diventa:

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

Importante

Come spiegato in precedenza, quando si usa MTP con VSTest, dotnet test è necessario un -- aggiuntivo prima degli argomenti da passare alla piattaforma. Quindi, questo 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 MTP.

xUnit.net, non supporta lo stesso formato di filtro durante l'esecuzione con MTP. È 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 di solito viene chiamato "logger" in VSTest viene chiamato "reporter" in MTP. In MTP 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 MTP, qualsiasi reporter). Ogni reporter MTP è libero di aggiungere una propria opzione della riga di comando e, di conseguenza, non esiste un'opzione della riga di comando centralizzata come 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 MTP, il comando diventa:

dotnet test --report-trx

Importante

Per usare --report-trx, è necessario che sia installato il Microsoft.Testing.Extensions.TrxReport pacchetto NuGet.

Importante

Come spiegato in precedenza, quando si usa MTP con VSTest basato su dotnet test, occorre un componente extra -- prima che gli argomenti da passare alla piattaforma. Quindi, questo 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 MTP ed è stato sostituito da un file di configurazione più moderno testconfig.json . Tuttavia, MSTest e NUnit supportano ancora runSettings precedenti durante l'esecuzione di MTP 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 usano Visual Studio o il Test Explorer di Visual Studio Code, potrebbe essere necessario abilitare il supporto per l'MTP.

Visual Studio

Visual Studio Esplora test supporta MTP 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 MTP.

Azure DevOps

Quando si usano Azure DevOps attività, potrebbe essere necessario aggiornare la pipeline per usare MTP, 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 MTP nativa 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 puntava, 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 MTP

Esecuzione di nessun test

Se un assembly di test ha eseguito zero test, VSTest tollera che e termina con esito positivo. Tuttavia, MTP 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 MTP.

  • Con MTP, la codifica è sempre preservata.
  • Con VSTest non in esecuzione in modalità di isolamento (il comportamento predefinito di vstest.console), tale codifica viene mantenuta, simile a MTP.
  • 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.

Suggerimento

Il motivo per cui la codifica non viene mantenuta con la modalità di isolamento VSTest è che il processo testhost viene avviato con CreateNoWindow = true. Quindi non è collegato alla console originale.

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.

  • Last updated on