Udostępnij za pośrednictwem

Microsoft.Testing.Platform — omówienie

Microsoft.Testing.Platform to lekka i przenośna alternatywa dla VSTest do uruchamiania testów w każdym kontekście, w tym w potokach ciągłej integracji (CI), wierszu poleceń, Eksploratorze testów w programie Visual Studio i Eksploratorze testów w programie VS Code. Platforma Microsoft.Testing.Platform jest osadzona bezpośrednio w projektach testowych i nie ma żadnych innych zależności aplikacji, takich jak vstest.console lub dotnet test potrzebne do uruchamiania testów.

Microsoft.Testing.Platform jest open source. Kod Microsoft.Testing.Platform można znaleźć w repozytorium microsoft/testfx GitHub.

Filarów Microsoft.Testing.Platform

Ta nowa platforma testowania jest oparta na środowisku zespołu testowania środowiska deweloperów platformy .NET i ma na celu rozwiązanie problemów napotykanych od czasu wydania platformy .NET Core w 2016 roku. Chociaż istnieje wysoki poziom zgodności między środowiskiem .NET Framework a platformą .NET Core/.NET, niektóre kluczowe funkcje, takie jak system wtyczek oraz nowe możliwe formy kompilacji w .NET, utrudniają rozwój lub pełne wsparcie nowych funkcji środowiska uruchomieniowego przy użyciu bieżącej architektury platformy VSTest.

Główne czynniki napędzane ewolucją nowej platformy testowej zostały szczegółowo opisane w następujących kwestiach:

  • deterministyczność: zapewnienie, że uruchamianie tych samych testów w różnych kontekstach (lokalnie, CI) spowoduje wygenerowanie tego samego wyniku. Nowe środowisko uruchomieniowe nie polega na odbiciu ani żadnej innej dynamicznej funkcji środowiska uruchomieniowego platformy .NET w celu koordynowania przebiegu testu.

  • Przezroczystość środowiska uruchomieniowego: Środowisko uruchomieniowe testów nie ingeruje w kod struktury testowej, nie tworzy izolowanych kontekstów, takich jak AppDomain lub AssemblyLoadContext, i nie używa refleksji ani niestandardowych rozwiązywaczy zestawów.

  • Rejestracja rozszerzeń w czasie kompilacji: rozszerzenia, takie jak struktury testowe i rozszerzenia poza procesem, są rejestrowane w czasie kompilacji w celu zapewnienia determinizmu i ułatwienia wykrywania niespójności.

  • zerowe zależności: rdzeniem platformy jest pojedynczy zestaw platformy .NET, Microsoft.Testing.Platform.dll, który nie ma zależności innych niż obsługiwane środowiska uruchomieniowe.

  • Hostable: środowisko uruchomieniowe testów może być hostowane w dowolnej aplikacji platformy .NET. Aplikacja konsolowa jest często używana do uruchamiania testów, ale można utworzyć aplikację testową w dowolnym typie aplikacji .NET. Dzięki temu można uruchamiać testy w specjalnych kontekstach, takich jak urządzenia lub przeglądarki, w których mogą występować ograniczenia.

  • Obsługa wszystkich formatów platformy .NET: Obsługa bieżących i przyszłych formatów platformy .NET, w tym Native AOT.

  • Wydajność: Znalezienie właściwej równowagi między funkcjami a punktami rozszerzenia, aby uniknąć rozrastania środowiska uruchomieniowego przez kod, który nie jest podstawowy. Nowa platforma testowa została zaprojektowana tak, aby "orkiestrować" przebieg testu, a nie dostarczać szczegółów implementacji na temat tego, jak to zrobić.

  • wystarczająco rozszerzalne: nowa platforma jest oparta na punktach rozszerzalności, aby umożliwić maksymalne dostosowanie wykonywania środowiska uruchomieniowego. Umożliwia skonfigurowanie hosta procesu testowania, obserwowanie procesu testowego i pozyskiwanie informacji z frameworka testowego w procesie hosta testowego.

  • wdrożenie pojedynczego modułu: funkcja hostowania umożliwia model wdrażania pojedynczego modułu, w którym pojedynczy wynik kompilacji może służyć do obsługi wszystkich punktów rozszerzalności, zarówno poza procesem, jak i w procesie, bez konieczności dostarczania różnych modułów wykonywalnych.

Obsługiwane platformy testowe

  • MSTest. W narzędziu MSTest obsługa Microsoft.Testing.Platform jest wykonywana za pośrednictwem modułu uruchamiającego MSTest.
  • NUnit. W NUnit obsługa Microsoft.Testing.Platform jest realizowana przez NUnit runner.
  • xUnit.net: W xUnit.net wsparcie Microsoft.Testing.Platform odbywa się za pośrednictwem uruchamiacza xUnit.net.
  • TUnit: całkowicie skonstruowany w oparciu o Microsoft.Testing.Platform, aby uzyskać więcej informacji, zobacz dokumentację TUnit .

Uruchamianie i debugowanie testów

Microsoft.Testing.Platform projekty testowe są tworzone jako pliki wykonywalne, które można uruchamiać (lub debugować) bezpośrednio. Nie ma dodatkowej konsoli ani polecenia do uruchamiania testów. Aplikacja kończy działanie z kodem zakończenia bezzerowym, jeśli występuje błąd, który jest typowy dla większości plików wykonywalnych. Aby uzyskać więcej informacji na temat znanych kodów wyjścia, zobacz kody wyjścia Microsoft.Testing.Platform.

Napiwek

Możesz zignorować określony kod zakończenia przy użyciu opcji wiersza polecenia --ignore-exit-code.

Można również ustawić opcje wiersza polecenia, które mają zastosowanie do określonego projektu testowego w pliku projektu przy użyciu właściwości TestingPlatformCommandLineArguments MSBuild. Jednym z typowych przypadków użycia są projekty testowe, w których wszystkie testy są ignorowane, które zwykle kończą się kodem wyjścia 8 (sesja testowa nie uruchomiła żadnych testów). W tym scenariuszu możesz dodać następujący tekst pod sekcję PropertyGroup w pliku projektu:

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

Ważny

Domyślnie Microsoft.Testing.Platform zbiera dane telemetryczne. Aby uzyskać więcej informacji i opcji rezygnacji, zobacz telemetrię Microsoft.Testing.Platform.

Publikowanie projektu testowego przy użyciu dotnet publish i bezpośrednie uruchamianie aplikacji jest innym sposobem uruchamiania testów. Na przykład wykonanie ./Contoso.MyTests.exe. W niektórych scenariuszach można również użyć dotnet build do utworzenia pliku wykonywalnego, ale mogą wystąpić przypadki brzegowe, takie jak natywny AOT.

Korzystanie z dotnet run

Polecenie dotnet run może służyć do kompilowania i uruchamiania projektu testowego. Jest to najprostszy, choć czasami najwolniejszy sposób uruchamiania testów. Korzystanie z dotnet run jest praktyczne podczas edytowania i uruchamiania testów lokalnie, ponieważ gwarantuje, że projekt testowy zostanie ponownie skompilowany w razie potrzeby. dotnet run również automatycznie znajdzie projekt w bieżącym folderze.

dotnet run --project Contoso.MyTests

Aby uzyskać więcej informacji na temat dotnet run, zobacz dotnet run.

Korzystanie z dotnet exec

Polecenie dotnet exec lub dotnet służy do wykonywania (lub uruchamiania) już skompilowany projekt testowy. Jest to alternatywa dla bezpośredniego uruchamiania aplikacji. dotnet exec wymaga ścieżki do skompilowanej biblioteki dll projektu testowego.

dotnet exec Contoso.MyTests.dll

lub

dotnet Contoso.MyTests.dll

Notatka

Podanie ścieżki do pliku wykonywalnego projektu testowego (*.exe) powoduje błąd:

Error:
  An assembly specified in the application dependencies manifest
  (Contoso.MyTests.deps.json) has already been found but with a different
  file extension:
    package: 'Contoso.MyTests', version: '1.0.0'
    path: 'Contoso.MyTests.dll'
    previously found assembly: 'S:\t\Contoso.MyTests\bin\Debug\net8.0\Contoso.MyTests.exe'

Aby uzyskać więcej informacji na temat dotnet exec, zajrzyj do dotnet exec.

Korzystanie z dotnet test

Microsoft.Testing.Platform oferuje warstwę zgodności z vstest.console.exe i dotnet test, dzięki czemu można uruchamiać testy tak jak wcześniej podczas włączania nowego scenariusza wykonywania.

dotnet test Contoso.MyTests.dll

Opcje

Poniższa lista zawiera tylko opcje platformy. Aby wyświetlić określone opcje wprowadzone przez każde rozszerzenie, zapoznaj się ze stroną dokumentacji rozszerzenia lub użyj opcji --help.

  • @

    Określa nazwę pliku odpowiedzi. Nazwa pliku odpowiedzi musi natychmiast podążać za znakiem @ bez odstępu między znakiem @ a nazwą pliku odpowiedzi.

    Opcje w pliku odpowiedzi są interpretowane tak, jakby były obecne w tym miejscu w wierszu polecenia. Każdy argument w pliku odpowiedzi musi rozpoczynać się i kończyć w tym samym wierszu. Nie można używać znaku ukośnika odwrotnego () do łączenia wierszy. Użycie pliku odpowiedzi pomaga w przypadku bardzo długich poleceń, które mogą przekroczyć limity terminalu. Plik odpowiedzi można połączyć z wbudowanymi argumentami wiersza polecenia. Na przykład:

    ./TestExecutable.exe @"filter.rsp" --timeout 10s

    gdzie filter.rsp może zawierać następującą zawartość:

    --filter "A very long filter"

    Można też użyć pojedynczego pliku rsp do określenia limitu czasu i filtru w następujący sposób:

    ./TestExecutable.exe @"arguments.rsp"

    --filter "A very long filter"
--timeout 10s

  • --config-file

    Określa plik testconfig.json.

  • --diagnostic

    Włącza rejestrowanie diagnostyczne. Domyślny poziom logowania to Trace. Plik jest zapisywany w katalogu wyjściowym z następującym formatem nazwy, log_[MMddHHssfff].diag.

  • --diagnostic-filelogger-synchronouswrite

    Wymusza synchroniczne zapisywanie logów przez wbudowany rejestrator plików. Przydatne w scenariuszach, w których nie chcesz utracić żadnych wpisów dziennika (jeśli proces ulegnie awarii). Spowoduje to spowolnienie wykonywania testu.

  • --diagnostic-output-directory

    Katalog wyjściowy rejestrowania diagnostycznego, jeśli nie został określony, plik jest generowany w domyślnym katalogu TestResults.

  • --diagnostic-output-fileprefix

    Prefiks nazwy pliku dziennika. Wartość domyślna to "log_".

  • --diagnostic-verbosity

    Definiuje poziom szczegółowości, gdy używany jest przełącznik --diagnostic. Dostępne wartości to Trace, Debug, Information, Warning, Errorlub Critical.

  • --exit-on-process-exit

    Zakończ proces testowy, jeśli proces zależny zakończy działanie. Należy podać piD.

  • --help

    Wyświetla opis sposobu używania polecenia .

  • --ignore-exit-code

    Zezwala na ignorowanie niektórych kodów zakończenia innych niż zero, i zamiast tego są zwracane jako 0. Aby uzyskać więcej informacji, sprawdź Ignoruj określone kody zakończenia.

  • --info

    Wyświetla zaawansowane informacje o aplikacji testowej .NET, takie jak:

    • Platforma.
    • Środowisko.
    • Każdy zarejestrowany dostawca wiersza polecenia, taki jak np. name, version, descriptioni options.
    • Każde zarejestrowane narzędzie, takie jak jego command, name, version, description, i wszyscy dostawcy wiersza polecenia.

    Ta funkcja służy do zrozumienia rozszerzeń, które będą rejestrować tę samą opcję wiersza polecenia lub zmiany dostępnych opcji między wieloma wersjami rozszerzenia (lub platformy).

  • --list-tests

    Wyświetl listę dostępnych testów. Testy nie zostaną wykonane.

  • --maximum-failed-tests

    Określa maksymalną liczbę niepowodzeń testów, które po osiągnięciu zatrzymają przebieg testu. Obsługa tego przełącznika wymaga od autorów platform zaimplementowania możliwości IGracefulStopTestExecutionCapability. Kod zakończenia po osiągnięciu tej liczby niepowodzeń testów wynosi 13. Aby uzyskać więcej informacji, zobacz Microsoft.Testing.Platform kody wyjścia.

    Notatka

    Ta funkcja jest dostępna w witrynie Microsoft.Testing.Platform, począwszy od wersji 1.5.

  • --minimum-expected-tests

    Określa minimalną liczbę testów, które mają zostać uruchomione. Domyślnie oczekuje się, że co najmniej jeden test zostanie uruchomiony.

  • --results-directory

    Katalog, w którym zostaną umieszczone wyniki testu. Jeśli określony katalog nie istnieje, zostanie utworzony. Wartość domyślna to TestResults w katalogu zawierającym aplikację testową.

  • --timeout

    Globalny limit czasu wykonywania testów. Przyjmuje jeden argument jako ciąg w formacie <value>[h|m|s], gdzie <value> jest liczbą zmiennoprzecinkową.

Integracja z programem MSBuild

Pakiet NuGet Microsoft.Testing.Platform.MSBuild udostępnia różne integracje Microsoft.Testing.Platform z programem MSBuild:

  • Obsługa dotnet test. Aby uzyskać więcej informacji, zobacz Testowanie za pomocą testu dotnet.
  • Obsługa ProjectCapability wymagana przez Eksploratory Testów Visual Studio i Visual Studio Code.
  • Automatyczne generowanie punktu wejścia (metodaMain).
  • Automatyczne generowanie pliku konfiguracji.

Notatka

Ta integracja działa w sposób przechodniy (projekt odwołujący się do innego projektu odwołującego się do tego pakietu będzie zachowywał się tak, jakby odwołuje się do pakietu) i można go wyłączyć za pośrednictwem właściwości IsTestingPlatformApplication MSBuild.

Zobacz też