Rozwiązywanie problemów z Microsoft.Testing.Platform (MTP)

Ten artykuł zawiera wskazówki dotyczące rozwiązywania problemów z protokołem MTP.

Kody zakończenia

MTP używa znanych kodów zakończenia do przekazywania błędów testu lub błędów aplikacji. Kody zakończenia zaczynają się od 0 i nie są ujemne.

Kod zakończenia	Szczegóły
0	Kod 0 zakończenia wskazuje powodzenie. Wszystkie testy wybrane do uruchomienia zostały uruchomione do ukończenia i nie wystąpiły żadne błędy.
1	Kod 1 zakończenia wskazuje na błędy o nieznanym charakterze i działa jako ogarnianie wszelkich przypadków. Aby znaleźć dodatkowe informacje o błędzie i szczegóły, poszukaj w danych wyjściowych.
2	Kod wyjścia 2 służy do wskazania, że wystąpiła co najmniej jedna awaria testu.
3	Kod 3 zakończenia wskazuje, że sesja testowa została przerwana. Sesję można przerwać przy użyciu klawiszy Ctrl+C, na przykład.
4	Kod 4 zakończenia wskazuje, że konfiguracja używanych rozszerzeń jest nieprawidłowa, a sesja testów nie może zostać uruchomiona.
5	Kod 5 zakończenia wskazuje na to, że argumenty wiersza polecenia przekazane do aplikacji testowej są nieprawidłowe.
6 (nie jest już używane)	Kod 6 zakończenia nie jest już generowany przez platformę; wcześniej wskazywał na to, że sesja testowa używa funkcji niezaimplementowanej.
7	Kod 7 zakończenia wskazuje, że sesja testowa nie mogła zakończyć się pomyślnie i prawdopodobnie uległa awarii. Możliwe, że jest to spowodowane przez sesję testową, która została uruchomiona za pośrednictwem punktu rozszerzenia kontrolera testów.
8	Kod zakończenia 8 wskazuje, że podczas sesji testowej nie uruchomiono żadnych testów w trybie ścisłym --zero-tests-policy.
9	Kod zakończenia 9 wskazuje, że uruchomienie wykonało mniej testów, niż wymaga tego --minimum-expected-tests, w tym zero testów.
10	Kod 10 zakończenia wskazuje, że adapter testowy, Testing.Platform Test Framework, MSTest, NUnit lub xUnit, nie może uruchomić testów z powodu infrastruktury niepowiązanej z własnym testem. Przykład polega na tym, że nie można utworzyć urządzenia wymaganego przez testy.
11	Kod zakończenia 11 wskazuje, że proces testowy zakończy swoje działanie, jeśli proces zależny zakończy działanie.
12	Kod 12 zakończenia wskazuje, że sesja testowa nie może zostać uruchomiona, ponieważ klient nie obsługuje żadnej z obsługiwanych wersji protokołu.
13	Kod 13 zakończenia wskazuje, że sesja testowa została zatrzymana z powodu osiągnięcia określonej liczby maksymalnych testów zakończonych niepowodzeniem przy użyciu --maximum-failed-tests opcji wiersza polecenia. Aby uzyskać więcej informacji, zobacz sekcję Opcje w dokumentacji opcji interfejsu wiersza polecenia MTP
14	Kod zakończenia 14 wskazuje, że zgodny moduł zbierający dane pokrycia zgłosił nieudaną ocenę progu pokrycia.

Jawna wartość --minimum-expected-tests ma pierwszeństwo przed --zero-tests-policy. Bez opcji „minimum” ścisła obsługa sprawdzania zera nadal używa kodu zakończenia 8.

Aby włączyć szczegółowe rejestrowanie i rozwiązać problemy, zobacz Rejestrowanie diagnostyczne.

Ignoruj określone kody zakończenia

Usługa MTP jest domyślnie przeznaczona do ścisłego stosowania, ale umożliwia konfigurowanie. W związku z tym użytkownicy mogą zdecydować, które kody zakończenia powinny być ignorowane (kod 0 zostanie zwrócony zamiast oryginalnego kodu zakończenia).

Aby zignorować określone kody zakończenia, użyj --ignore-exit-code opcji wiersza polecenia lub zmiennej środowiskowej TESTINGPLATFORM_EXITCODE_IGNORE . Akceptowany prawidłowy format to rozdzielana średnikami lista kodów zakończenia do zignorowania (na przykład --ignore-exit-code 2;3;8). Typowym scenariuszem jest rozważenie, że błędy testowe nie powinny skutkować kodem zakończenia niezerowym (co odpowiada ignorowaniu kodu 2zakończenia).

Rejestrowanie diagnostyczne

Platforma udostępnia wbudowane rejestrowanie diagnostyczne, które ułatwia rozwiązywanie problemów z wykonywaniem testów. Rejestrowanie diagnostyczne można włączyć za pomocą opcji wiersza polecenia lub zmiennych środowiskowych.

Opcje wiersza polecenia

Następujące opcje platformy zawierają przydatne informacje dotyczące rozwiązywania problemów z aplikacjami testowymi:

• --info
• --diagnostic
• --diagnostic-synchronous-write
• --diagnostic-verbosity
• --diagnostic-file-prefix
• --diagnostic-output-directory

Zmienne środowiskowe

Dzienniki diagnostyczne można również włączyć przy użyciu zmiennych środowiskowych:

Nazwa zmiennej środowiskowej	Opis
TESTINGPLATFORM_DIAGNOSTIC	Jeśli ustawiono wartość 1, włącza rejestrowanie diagnostyczne.
TESTINGPLATFORM_DIAGNOSTIC_VERBOSITY	Definiuje poziom szczegółowości. Dostępne wartości to Trace, Debug, Information, Warning, Errorlub Critical.
TESTINGPLATFORM_DIAGNOSTIC_OUTPUT_DIRECTORY	Katalog wyjściowy dla rejestrowania diagnostycznego; jeśli katalog nie został określony, plik jest generowany w domyślnym katalogu TestResults.
TESTINGPLATFORM_DIAGNOSTIC_FILE_PREFIX	Prefiks nazwy pliku dziennika. Ustawienie domyślne powoduje wygenerowanie <asm>_<tfm>_<arch>_<timestamp>.diag. Dostępne w MTP począwszy od wersji 2.3.0; starsza nazwa TESTINGPLATFORM_DIAGNOSTIC_OUTPUT_FILEPREFIX jest nadal honorowana w celu zachowania zgodności z poprzednimi wersjami.
TESTINGPLATFORM_DIAGNOSTIC_SYNCHRONOUS_WRITE	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. Dostępne w MTP począwszy od wersji 2.3.0; starsza nazwa TESTINGPLATFORM_DIAGNOSTIC_FILELOGGER_SYNCHRONOUSWRITE jest nadal honorowana w celu zachowania zgodności z poprzednimi wersjami.

Uwaga / Notatka

Zmienne środowiskowe mają pierwszeństwo przed argumentami wiersza polecenia.

Protokół MTP zapisuje plik diagnostyczny dla każdego źródła testów. Jeśli dwa pliki mają ten sam znacznik czasu, MTP dodaje sufiks z identyfikatorem procesu i licznikiem zamiast nadpisywać istniejący plik.

Rozwiązywanie problemów z błędami konfiguracji

Microsoft.Testing.Platform.MSBuild

Poniżej przedstawiono typowe błędy konfiguracji związane z programem Microsoft.Testing.Platform.MSBuild.

błąd CS8892: Metoda 'TestingPlatformEntryPoint.Main(string[])' nie będzie używana jako punkt wejścia, ponieważ znaleziono synchroniczny punkt wejścia 'Program.Main(string[])'

Ręczne definiowanie punktu wejścia (Main) w projekcie testowym lub odwoływanie się do projektu testowego z aplikacji, która ma już punkt wejścia powoduje konflikt z punktem wejścia wygenerowanym przez MTP. Aby uniknąć tego problemu, wykonaj jedną z następujących czynności:

• Usuń ręcznie zdefiniowany punkt wejścia, zazwyczaj metodę Main w pliku Program.cs, i pozwól, aby platforma testowa wygenerowała go za Ciebie.

• Wyłącz generowanie punktu wejścia, ustawiając właściwość <GenerateTestingPlatformEntryPoint>false</GenerateTestingPlatformEntryPoint> MSBuild.

• Aby całkowicie wyłączyć zależność przechodnią do Microsoft.Testing.Platform.MSBuild, ustaw właściwość <IsTestingPlatformApplication>false</IsTestingPlatformApplication> MSBuild w projekcie, który odwołuje się do projektu testowego. Jest to konieczne, gdy odwołujesz się do projektu testowego z projektu nietestowego, na przykład aplikacji konsolowej, która odwołuje się do aplikacji testowej.

Wygenerowana przestrzeń nazw kodu koliduje z typem referencyjnym

Microsoft.Testing.Platform.MSBuild generuje typy SelfRegisteredExtensions i TestingPlatformEntryPoint wewnątrz $(RootNamespace) projektu. Domyślnie element RootNamespace ma taką samą nazwę jak projekt, co może powodować konflikt z typem o tej samej w pełni kwalifikowanej nazwie udostępnianym przez zestaw, do którego istnieje odwołanie.

Na przykład projekt o nazwie System.Security.Cryptography.ProtectedData.Tests kończy się generowaniem kodu w System.Security.Cryptography.ProtectedData przestrzeni nazw. Jeśli projekt odwołuje się również do pakietu NuGet System.Security.Cryptography.ProtectedData, który zawiera publiczny typ ProtectedData w przestrzeni nazw System.Security.Cryptography, kompilator nie jest już w stanie jednoznacznie rozróżnić między wygenerowaną przestrzenią nazw a typem, do którego istnieje odwołanie, i zgłasza błędy, takie jak CS0118 („ProtectedData” jest przestrzenią nazw, ale jest używana jak typ).

Aby rozwiązać konflikt, ustaw w projekcie testowym element RootNamespace na wartość, która nie powoduje kolizji z żadnym typem, do którego istnieje odwołanie:

<PropertyGroup>
  <RootNamespace>System.Security.Cryptography.ProtectedDataTests</RootNamespace>
</PropertyGroup>

Można również wyczyścić RootNamespace całkowicie (<RootNamespace />), w którym przypadku wygenerowane typy są emitowane do globalnej przestrzeni nazw.

Microsoft.Testing.Extensions.Fakes

Nie udało się ustalić ścieżki profilera z zmiennych środowiskowych COR_PROFILER_PATH i COR_PROFILER.

Ten błąd może wystąpić, jeśli nie wszystkie zestawy Fakes są obecne w folderze bin.

• Upewnij się, że projekt używa MSTest.SDK lub odwołań Microsoft.Testing.Extensions.Fakes.
• W przypadku projektów .NET Framework należy unikać ustawienia <PlatformTarget>AnyCPU</PlatformTarget>, ponieważ powoduje to, że program NuGet nie kopiuje wszystkich plików do folderu bin.

Nierozpoznana opcja wiersza polecenia rozszerzenia

Opcja wiersza polecenia właściwa dla rozszerzenia może zakończyć się kodem wyjścia 5, gdy aplikacja testowa nie rejestruje pakietu udostępniającego tę opcję. Na przykład --report-trx wymaga Microsoft.Testing.Extensions.TrxReport, albo jako bezpośredniego odwołania do pakietu, albo za pośrednictwem konfiguracji lub profilu testowego zestawu SDK, które zawierają pakiet. Rdzeń MTP nie obejmuje raportów, pokrycia kodu, zrzutu, ponawiania prób ani innych opcji rozszerzenia.

Uruchom aplikację testową za pomocą --help lub uruchom dotnet test --help w trybie MTP, aby potwierdzić, że opcja jest dostępna. Jeśli brakuje opcji, dodaj pakiet rozszerzenia lub włącz rozszerzenie za pomocą zestawu SDK testowego. Zobacz Opcje rozszerzenia według scenariusza , aby znaleźć wymagany pakiet.

Ten sam błąd występuje, gdy rozwiązanie zawiera projekty korzystające z różnych frameworków testowych (na przykład MSTest i xUnit.net) lub różnych zestawów rozszerzeń (na przykład tylko niektóre projekty odwołują się do Microsoft.Testing.Extensions.HangDump). Opcja jest prawidłowa dla jednego projektu, ale nierozpoznana przez inny.

Aby rozwiązać ten problem, użyj TestingPlatformCommandLineArguments właściwości MSBuild z warunkami, aby kierować argumenty do odpowiednich projektów. Aby uzyskać szczegółowe instrukcje, zobacz Rozwiązania z mieszanymi strukturami testowymi lub rozszerzeniami.