Udostępnij za pośrednictwem

Microsoft.Testing.Platform — omówienie

  • Artykuł

Microsoft.Testing.Platform to uproszczona i przenośna alternatywa dla programu VSTest do uruchamiania testów we wszystkich kontekstach, w tym potoków ciągłej integracji, interfejsu wiersza polecenia, Eksploratora testów programu Visual Studio i Eksploratora tekstu programu 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 oprogramowaniem open source. Kod można znaleźć Microsoft.Testing.Platform w repozytorium Microsoft/testfx w witrynie GitHub.

Filary 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 programem .NET Framework i platformą .NET Core/.NET, niektóre kluczowe funkcje, takie jak system wtyczek i nowe możliwe czynniki form kompilacji platformy .NET, sprawiły, że była złożona, aby ewoluować lub w pełni obsługiwać nową funkcję ś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:

  • Determinizm: Zapewnienie, że uruchamianie tych samych testów w różnych kontekstach (local, 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 zakłóca kodu platformy testowej, nie tworzy izolowanych kontekstów, takich jak AppDomain lub AssemblyLoadContext, i nie używa odbicia ani niestandardowych programów rozpoznawania 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.

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

  • Hostable: środowisko uruchomieniowe testowe 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 czynników formularzy platformy .NET: Obsługa bieżących i przyszłych czynników formularzy platformy .NET, w tym macierzystym AOT.

  • Wydajne: znalezienie właściwej równowagi między funkcjami i punktami rozszerzenia, aby uniknąć wzdęcia środowiska uruchomieniowego przy użyciu kodu innego niż 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 używanie informacji z platformy testowej w procesie hosta testowego.

  • Wdrożenie pojedynczego modułu: funkcja hostability umożliwia wdrożenie modelu 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

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 dodatkowego testu z uruchomioną konsolą lub poleceniem. Aplikacja kończy działanie z kodem zakończenia niezerowym, jeśli występuje błąd, jak zwykle w przypadku większości plików wykonywalnych. Aby uzyskać więcej informacji na temat znanych kodów zakończenia, zobacz Microsoft.Testing.Platform exit codes (Kody zakończenia platformy Microsoft.Testing.Platform).

Ważne

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

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

Korzystanie z polecenia 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. Użycie dotnet run jest praktyczne podczas edytowania i uruchamiania testów lokalnie, ponieważ gwarantuje, że projekt testowy zostanie ponownie skompilowany w razie potrzeby. dotnet run program automatycznie znajdzie również projekt w bieżącym folderze.

dotnet run --project Contoso.MyTests

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

Korzystanie z polecenia dotnet exec

Polecenie dotnet exec or 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 skompilowanych bibliotek dll projektu testowego.

dotnet exec Contoso.MyTests.dll

or

dotnet Contoso.MyTests.dll

Uwaga

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

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 execprogramu , zobacz dotnet exec.

Korzystanie z polecenia dotnet test

Microsoft.Testing.Platform oferuje warstwę zgodności i vstest.console.exedotnet test zapewnia możliwość uruchamiania testów 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 --help opcji .

  • @

    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 mieć 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ślnym poziomem dziennika jest Trace. Plik jest zapisywany w katalogu wyjściowym o następującym formacie nazwy: log_[MMddHHssfff].diag.

  • --diagnostic-filelogger-synchronouswrite

    Wymusza wbudowany rejestrator plików w celu synchronicznego zapisywania dziennikó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 określono pliku, 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 --diagnostic jest używany przełącznik. Dostępne wartości to Trace, , Debug, InformationWarning, , 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, a zamiast tego zwracane jako 0. Aby uzyskać więcej informacji, zobacz 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 name, version, descriptioni options.
    • Każde zarejestrowane narzędzie, takie jak command, name, version, descriptioni 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 przy liczbie niepowodzeń testów wynoszącej 13. Aby uzyskać więcej informacji, zobacz Microsoft.Testing.Platform exit codes.

    Uwaga

    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 znajduje TestResults się 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 Microsoft.Testing.Platform:

  • Obsługa programu dotnet test. Aby uzyskać więcej informacji, zobacz dotnet test integration (Integracja z testem dotnet).
  • Obsługa wymagana ProjectCapability przez Visual Studio eksploratory testów i Visual Studio Code .
  • Automatyczne generowanie punktu wejścia (Main metoda).
  • Automatyczne generowanie pliku konfiguracji.

Uwaga

Ta integracja działa w sposób przejściowy (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 pomocą IsTestingPlatformApplication właściwości MSBuild.

Zobacz też