Udostępnij za pomocą


Migrowanie z programu VSTest do microsoft.Testing.Platform

Z tego artykułu dowiesz się, jak przeprowadzić migrację z programu VSTest do witryny Microsoft.Testing.Platform.

Zgoda na korzystanie z microsoft.Testing.Platform

Początkowym krokiem migracji jest zdecydowanie się na korzystanie z Microsoft.Testing.Platform.

Dla wszystkich frameworków testowych dodaj <OutputType>Exe</OutputType> do wszystkich projektów testowych w rozwiązaniu. Następnie postępuj zgodnie ze wskazówkami specyficznymi dla platformy.

MSTest

Platforma Microsoft.Testing.Platform jest obsługiwana przez narzędzie MSTest, począwszy od wersji 3.2.0. Zalecamy jednak zaktualizowanie do najnowszej dostępnej wersji MSTest.

Aby wyrazić zgodę, dodaj <EnableMSTestRunner>true</EnableMSTestRunner> pod elementem PropertyGroup w pliku Directory.Build.props.

Uwaga / Notatka

W przypadku korzystania z zestawu MSTest.Sdk platforma Microsoft.Testing.Platform jest domyślnie używana, chyba że <UseVSTest>true</UseVSTest> zostanie określona.

NUnit

Platforma Microsoft.Testing.Platform jest obsługiwana przez serwer NUnit3TestAdapter, począwszy od wersji 5.0.0.

Aby wyrazić zgodę, dodaj <EnableNUnitRunner>true</EnableNUnitRunner> pod PropertyGroup w pliku Directory.Build.props.

xUnit.net

Platforma Microsoft.Testing.Platform jest obsługiwana od xunit.v3.

Aby wyrazić zgodę, dodaj <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> pod PropertyGroup w pliku Directory.Build.props.

dotnet test

Zgoda na zestaw .NET 9 SDK i jego wcześniejsze wersje

W zestawie .NET 9 SDK i starszych wersjach nie ma natywnej obsługi zestawu Microsoft.Testing.Platform dla programu dotnet test. Obsługa jest oparta na infrastrukturze VSTest. Aby tego użyć, dodaj <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> pod PropertyGroup w pliku Directory.Build.props.

Ważne

W przypadku uruchamiania obsługi Microsoft.Testing.Platform w tym trybie należy dodać --, oddzielając dotnet test od nowych argumentów platformy. Na przykład dotnet test --no-build -- --list-tests.

Zgoda na korzystanie z zestawu .NET 10 SDK i nowszych wersji

Począwszy od zestawu .NET 10 SDK, istnieje natywna obsługa biblioteki Microsoft.Testing.Platform. Aby go użyć, należy określić moduł uruchamiający testy, jak Microsoft.Testing.Platform w global.json:

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

Ważne

W tym trybie dodatkowa -- nie jest już używana.

Zaktualizuj wywołania dotnet test

Opcje dotnet test wiersza polecenia są podzielone na dwie kategorie: argumenty związane z kompilacją i powiązane z testami.

Argumenty związane z kompilacją nie mają znaczenia dla platformy testowej i w związku z tym nie muszą być aktualizowane dla nowej platformy. Argumenty związane z kompilacją są wymienione tutaj:

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

Argumenty związane z testem są specyficzne dla programu VSTest i dlatego należy je przekształcić w celu dopasowania do nowej platformy. W poniższej tabeli przedstawiono mapowanie między argumentami VSTest a nową platformą:

Argument VSTest Nowy parametr platformy
--test-adapter-path <ADAPTER_PATH> Nie dotyczy platformy Microsoft.Testing.Platform
--blame Nie dotyczy platformy Microsoft.Testing.Platform
--blame-crash --crashdump (wymaga rozszerzenia zrzutu pamięci)
--blame-crash-dump-type <DUMP_TYPE> --crashdump-type (wymaga rozszerzenia zrzutu awaryjnego)
--blame-crash-collect-always Niewspierane
--blame-hang --hangdump (wymaga rozszerzenia "Hang dump")
--blame-hang-dump-type <DUMP_TYPE> --hangdump-type (wymaga rozszerzenia zrzutu zawieszania)
--blame-hang-timeout <TIMESPAN> --hangdump-timeout (wymaga Hang Dump Extension)
--collect <DATA_COLLECTOR_NAME> Zależy od modułu zbierającego dane
-d\|--diag <LOG_FILE> --diagnostic
--filter <EXPRESSION> Zależy od wybranej platformy testowej
-l\|--logger <LOGGER> Zależy od rejestratora
--results-directory <RESULTS_DIR> --results-directory <RESULTS_DIR>
-s\|--settings <SETTINGS_FILE> Zależy od wybranej platformy testowej
-t\|--list-tests --list-tests
-- <RunSettings arguments> --test-parameter (dostarczone przez VSTestBridge)

--collect

--collect to ogólny punkt rozszerzalności w programie VSTest dla dowolnego modułu zbierającego dane. Model rozszerzalności microsoft.Testing.Platform różni się i nie ma tak scentralizowanego argumentu, który ma być używany przez wszystkie moduły zbierające dane. W przypadku platformy Microsoft.Testing.Platform każdy moduł zbierający dane może dodać własną opcję wiersza polecenia. Na przykład uruchomienie programu Microsoft CodeCoverage za pośrednictwem programu VSTest może być podobne do następujących:

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

W przypadku platformy Microsoft.Testing.Platform staje się to:

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

Ważne

Jak wyjaśniono wcześniej, gdy korzysta się z Microsoft.Testing.Platform z komponentem opartym na VSTest dotnet test, przed przekazaniem argumentów do platformy potrzebne są dodatkowe --. Tak więc to staje się dotnet test -- --coverage --coverage-output-format cobertura.

--filter

--filter jest filtrem opartym na programie VSTest.

Narzędzia MSTest i NUnit obsługują ten sam format filtru, nawet w przypadku uruchamiania przy użyciu biblioteki Microsoft.Testing.Platform.

xUnit.net nie obsługuje tego samego formatu filtru w przypadku uruchamiania w programie Microsoft.Testing.Platform. Należy przeprowadzić migrację z filtru opartego na VSTest do nowej obsługi filtru w xunit.v3, co jest realizowane za pomocą następujących opcji wiersza poleceń.

Opcje specyficzne dla xUnit.net:

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

Aby uzyskać więcej informacji, zobacz dokumentację Microsoft.Testing.Platform dotyczącą języka xUnit.net i języka filtrowania zapytań dla xUnit.net.

--logger

To, co zwykle nazywało się "rejestratorem" w programie VSTest, jest określane jako "reporter" w witrynie Microsoft.Testing.Platform. W witrynie Microsoft.Testing.Platform rejestrowanie jest jawnie przeznaczone tylko do celów diagnostycznych.

Podobnie jak --collect, --logger jest ogólnym punktem rozszerzalności w programie VSTest dla dowolnego rejestratora (lub, w kontekście Microsoft.Testing.Platform, dowolnego reportera). Każdy reporter Microsoft.Testing.Platform ma możliwość dodania własnej opcji wiersza polecenia; tak więc nie ma scentralizowanej opcji wiersza polecenia, takiej jak VSTest.--logger

Jednym z bardzo często używanych rejestratorów VSTest jest rejestrator TRX. Ten rejestrator jest zwykle wywoływany w następujący sposób:

dotnet test --logger trx

W przypadku platformy Microsoft.Testing.Platform polecenie staje się następujące:

dotnet test --report-trx

Ważne

Aby użyć --report-trx, musisz mieć zainstalowany pakiet NuGet Microsoft.Testing.Extensions.TrxReport.

Ważne

Jak wyjaśniono wcześniej, w przypadku korzystania z platformy Microsoft.Testing.Platform z bazą dotnet testdanych VSTest potrzebne są dodatkowe -- informacje przed przekazaniem argumentów do platformy. Tak więc staje się to dotnet test -- --report-trx.

--settings

Narzędzia VSTest's --settings są używane do określenia pliku RunSettings dla uruchomienia testów. Element RunSettings nie jest obsługiwany przez podstawowy Microsoft.Testing.Platform i został zastąpiony przez bardziej nowoczesny plik konfiguracji testconfig.json. Jednak narzędzia MSTest i NUnit nadal obsługują stare ustawienia RunSettings podczas uruchamiania platformy Microsoft.Testing.Platform i --settings są nadal obsługiwane.

vstest.console.exe

Jeśli używasz vstest.console.exe bezpośrednio, zalecamy zastąpienie go poleceniem dotnet test .

Eksplorator testów

W przypadku korzystania z programu Visual Studio lub Eksploratora testów programu Visual Studio Code może być konieczne włączenie obsługi biblioteki Microsoft.Testing.Platform.

Visual Studio

Eksplorator testów programu Visual Studio obsługuje platformę Microsoft.Testing.Platform, począwszy od wersji 17.14. Jeśli używasz starszej wersji, może być konieczne zaktualizowanie programu Visual Studio do najnowszej wersji.

Visual Studio Code

Program Visual Studio Code z zestawem deweloperskim języka C# obsługuje bibliotekę Microsoft.Testing.Platform.

Azure DevOps

W przypadku korzystania z zadań Azure DevOps, może być konieczne zaktualizowanie potoku do używania Microsoft.Testing.Platform, zależnie od tego, które zadanie jest używane.

VsTest, zadanie

Jeśli używasz zadania VSTest w usłudze Azure DevOps, możesz zastąpić je zadaniem platformy .NET Core.

Zadanie interfejsu wiersza polecenia platformy .NET Core

  • Jeśli przekazano niestandardowe arguments do zadania, postępuj zgodnie z tymi samymi wskazówkami dotyczącymi migracji dotnet test.

  • Jeśli używasz zadania DotNetCoreCLI i nie włączasz natywnego środowiska Microsoft.Testing.Platform dla zestawu .NET 10 SDK i nowszego za pośrednictwem pliku global.json, musisz skonfigurować zadanie arguments, aby poprawnie wskazywało na katalog wyników używany wcześniej, jak również na żądany raport TRX. Przykład:

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