Raporty testowe

Każda opcja raportu wymaga pakietu rozszerzeń wymienionego w odpowiedniej sekcji. Dodaj pakiet bezpośrednio lub użyj konfiguracji lub profilu zestawu SDK testów, który go zawiera. Rozszerzenia raportów nie należą do rdzenia MTP, więc opcja taka jak --report-trx nie jest rozpoznawana, gdy aplikacja testowa nie zarejestruje swojego rozszerzenia. Uruchom aplikację testową za pomocą --help lub uruchom dotnet test --help w trybie MTP, aby potwierdzić, że opcja jest dostępna.

Nazwy plików raportu

Każde rozszerzenie raportowania zapisuje swój plik w katalogu wyników testów, który można określić za pomocą opcji --results-directory. Aby zastąpić nazwę, użyj odpowiedniej --report-*-filename opcji. Każda sekcja raportu zawiera domyślną nazwę tego raportu.

Nazwa pliku może zawierać ścieżkę względną, która pozostaje w katalogu wyników testów, i może użyć następujących elementów zastępczych (symboli zastępczych):

Na przykład --report-trx-filename "{asm}_{tfm}_{arch}.trx" odtwarza domyślną nazwę TRX.

Jeśli dla źródła testowego istnieje już domyślna lub jawna nazwa pliku TRX, HTML lub JUnit, rozszerzenie ostrzega i zastępuje plik. Począwszy od wersji zapoznawczej MTP 2.4, funkcja CTRF używa tego samego zachowania. Aby zachować historię raportów, uwzględnij wartość {time}.

Konsolidacja raportów

Od wersji MTP 2.4.0 MTP automatycznie dodatkowo przetwarza artefakty raportu po uruchomieniu dotnet test, które uruchamia wiele modułów testowych, lub gdy mechanizm ponawiania wykonuje wiele prób. Funkcja jest eksperymentalna w MTP 2.4.0.

Rozszerzenia TRX, JUnit, CTRF i HTML grupują zgodne artefakty według rodzaju raportu i zapisują skonsolidowany raport w podkatalogu merged katalogu wyników testów. Konsolidacja CTRF łączy wyniki modułów i scala ponowione próby w końcowy wynik testu wraz z historią ponowień. Konsolidacja HTML tworzy scalone podsumowanie i zachowuje oryginalne raporty dla poszczególnych procesów.

W przypadku niestandardowych rozszerzeń raportów eksperymentalny IArtifactPostProcessor interfejs API uwidacznia oddzielne TestModules i RetryAttempts tryby przetwarzania. Aby uzyskać więcej informacji, zobacz RozszerzeniaIArtifactPostProcessor.

Visual Studio raporty testowe (TRX)

Plik wyników testu Visual Studio (lub TRX) jest domyślnym formatem publikowania wyników testu. To rozszerzenie wymaga pakietu NuGet Microsoft.Testing.Extensions.TrxReport .

Rejestracja ręczna

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddTrxReportProvider();

Opcje

Raport jest zapisywany w domyślnym folderze TestResults, który można określić za pomocą argumentu wiersza polecenia --results-directory.

Raporty HTML

Raport HTML tworzy interaktywny, samodzielny plik HTML na potrzeby sesji testowej. To rozszerzenie wymaga pakietu NuGet Microsoft.Testing.Extensions.HtmlReport.

Rejestracja ręczna

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddHtmlReportProvider();

Opcje

Raporty JUnit

Raport JUnit tworzy plik XML zgodny ze standardem JUnit na potrzeby sesji testowej. To rozszerzenie wymaga Microsoft. Testing.Extensions.JUnitReport NuGet package.

Rejestracja ręczna

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddJUnitReportProvider();

Opcje

Raporty CTRF

Raport CTRF tworzy plik JSON, który używa formatu Common Test Report Format na potrzeby sesji testowej. To rozszerzenie wymaga Microsoft. Testing.Extensions.CtrfReport NuGet package.

Rejestracja ręczna

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddCtrfReportProvider();

Opcje

Począwszy od wersji zapoznawczej MTP 2.4, CTRF zachowuje każdy wynik, gdy wiele testów używa tego samego identyfikatora UID. Zawiera również załączniki dla poszczególnych testów i poprzednich prób oraz określa ich typy MIME na podstawie nazw plików.

W przypadku ponownych testów funkcja CTRF koreluje próby tylko wtedy, gdy relacja jest jednoznaczna. Następnie rejestruje wcześniejsze próby w retryAttempts, ustawia retriesi oznacza później pomyślny wynik jako flaky: true. Niejednoznaczne wyniki tego samego identyfikatora UID pozostają oddzielne, więc raport nie kojarzy diagnostyki z niewłaściwym testem.

Podsumowanie terminalu identyfikuje niestabilne i ponawiane testy. Raporty TRX i JUnit zachowują jeden wynik końcowy na test zamiast rejestrować każdą próbę.

raporty Azure DevOps

Azure DevOps wtyczka raportów rozszerza uruchamianie testów dla deweloperów, którzy hostują swój kod na GitHub, ale bazują na agentach kompilacji Azure DevOps. Dodaje dodatkowe informacje do niepowodzeń, aby pokazać błąd bezpośrednio w GitHub pull request.

To rozszerzenie wymaga pakietu NuGet Microsoft.Testing.Extensions.AzureDevOpsReport .

Rejestracja ręczna

var builder = await TestApplication.CreateBuilderAsync(args);
builder.TestHost.AddAzureDevOpsProvider();

Opcje

Rozszerzenie automatycznie wykrywa, że działa w środowisku ciągłej integracji( CI), sprawdzając zmienną TF_BUILD środowiskową.

Od wersji MTP 2.4.0 podsumowania Markdown w Azure DevOps agregują wyniki ze wszystkich modułów testowych w wywołaniu dotnet test. Po włączeniu pokrycia kodu podsumowanie zawiera uwzględnione i łączne liczby, wartości procentowe, wyniki progowe i wskaźnik, gdy dane pokrycia są częściowe.

W wersji zapoznawczej MTP 2.4 publikowanie na bieżąco automatycznie przesyła załączniki plików dla nieudanych wyników do wyników testów w usłudze Azure DevOps. Wyniki zakończone niepowodzeniem obejmują niepowodzenie, błędy, przekroczenie limitu czasu i anulowane wyniki.

Gdy wynik dostarcza standardowe dane wyjściowe lub standardowy błąd, rozszerzenie może dołączyć do 256 KiB każdego strumienia wbudowanego. Każdy załącznik oparty na pliku ma limit 16 MiB.

Rozszerzenie przesyła również pliki na poziomie uruchomienia .coverage, .cobertura.xml i .opencover.xml jako załączniki pokrycia kodu. Te załączniki przebiegu testów i wyników są niezależne od --report-azdo-upload-artifacts, który przesyła wybrane pliki jako artefakty kompilacji w Azure Pipelines.

W przypadku ponownych testów Azure DevOps publikuje wcześniejsze próby jako podwyrażenia i dołącza artefakty każdej próby do podresultu, który je wygenerował. Jeśli korelacja bezpiecznego ponawiania prób jest niedostępna, rozszerzenie publikuje oddzielny wynik zamiast usuwać go.

Gdy publikowanie na żywo utworzy przebieg, zostanie wyświetlony adres URL przebiegu, dzięki czemu będzie można śledzić wyniki przed jego zakończeniem. Wysyła również pipelineReference i datę rozpoczęcia, gdy środowisko potoku je udostępnia. Na karcie Testy kompilacji nie jest wyświetlany trwający przebieg; jest on wyświetlany dopiero po zakończeniu.

raporty GitHub Actions

Raport GitHub Actions emituje natywne polecenia przepływu pracy GitHub Actions, dzięki czemu uruchomienia testów zapewniają najwyższej jakości obsługę na runnerze: grupy dzienników dla każdego zestawu, adnotacje dotyczące nieudanych i pominiętych testów (widoczne na karcie Adnotacje przepływu pracy oraz — gdy można ustalić lokalizację w kodzie źródłowym — w widoku różnic na karcie Files changed żądania pull request), podsumowanie zadania w formacie Markdown dołączane do pliku wskazanego przez GITHUB_STEP_SUMMARY, a także powiadomienia o wolnych testach.

To rozszerzenie wymaga pakietu NuGet Microsoft.Testing.Extensions.GitHubActionsReport.

Rozszerzenie aktywuje się tylko wtedy, gdy uruchomienie odbywa się w GitHub Actions (zmienna środowiskowa GITHUB_ACTIONS ma wartość true) i ustawiono przełącznik --report-gh; w przeciwnym razie nie robi nic. Po aktywowaniu każda funkcja jest domyślnie włączona i można ją wyłączyć osobno za pomocą opcji --report-gh-*.

Rejestracja ręczna

var builder = await TestApplication.CreateBuilderAsync(args);
builder.AddGitHubActionsProvider();

Opcje

Od wersji MTP 2.4.0 podsumowania Markdown w GitHub Actions agregują wyniki ze wszystkich modułów testowych w ramach wywołania dotnet test. Po włączeniu również pokrycia kodu wybierz coverage lub all, aby uwzględnić liczbę elementów objętych pokryciem i ich łączną liczbę, wartości procentowe, wyniki względem progów oraz wskaźnik informujący, że dane pokrycia są częściowe.

Szczegóły błędu mieszczą się w przydzielonych limitach komunikatu, stosu, licznika błędów i całego podsumowania. Gdy treść przekracza limit, raport obcina ją lub skraca i odnotowuje to skrócenie w podsumowaniu.