Pokrycie kodu w Bazelu

Bazel udostępnia podpolecenie coverage, które umożliwia generowanie raportów o zasięgu kodu w repozytoriach, które można przetestować za pomocą bazel coverage. Ze względu na idiosynchronizację różnych ekosystemów językowych nie ma problemu.

Ta strona zawiera ogólny opis tworzenia i wyświetlania raportów pokrycia, a także dodatkowe uwagi dotyczące języków, których konfiguracja jest dobrze znana. Najlepiej zapoznaj się najpierw z sekcją ogólną, a potem z zasadami dotyczącymi konkretnego języka. Zwróć też uwagę na sekcję wykonywania zdalnego, która wymaga dodatkowych działań.

Chociaż można dużo dostosować dokument, ten dokument skupia się na tworzeniu i używaniu raportów lcov, co jest obecnie najbardziej przydatną trasą.

Tworzenie raportu pokrycia

Przygotowania

Podstawowy proces tworzenia raportów pokrycia wymaga tych działań:

  • Podstawowe repozytorium z testowymi celami
  • Zestaw narzędzi z zainstalowanymi narzędziami do obsługi kodu w różnych językach
  • Prawidłowa konfiguracja „instrumentacji”

Dwa pierwsze są związane z konkretnym językiem i w większości proste, ale ten drugi może być trudniejszy w przypadku złożonych projektów.

„Instrumentacja” w tym przypadku odnosi się do narzędzi pokrycia używanych w przypadku konkretnego celu. Bazel zezwala na włączanie ich dla określonego podzbioru plików za pomocą flagi --instrumentation_filter, która określa filtr dla celów testowanych z instrumentem włączono. Aby włączyć instrumentacje na potrzeby testów, wymagana jest flaga --instrument_test_targets.

Domyślnie Bazel próbuje dopasować pakiety docelowe i drukuje odpowiedni filtr jako wiadomość INFO.

Bieżące pokrycie

Aby wygenerować raport Stan w indeksie, użyj narzędzia bazel coverage --combined_report=lcov [target]. Przeprowadza to testy celu, generując raporty o zasięgu w formacie lcov dla każdego pliku.

Po zakończeniu bazel uruchamia działanie, które zbiera wszystkie utworzone pliki coverów i łączy je w jedny, który na koniec zostaje utworzony w lokalizacji $(bazel info output_path)/_coverage/_coverage_report.dat.

Raporty o zasięgu są również generowane w przypadku negatywnego wyniku testu. Pamiętaj jednak, że nie obejmuje to testów zakończonych niepowodzeniem, a raportowane są tylko testy zakończone powodzeniem.

Wyświetlanie zasięgu

Raport pokrycia jest wyświetlany tylko w formacie lcov, który nie jest czytelny dla człowieka. Następnie możemy użyć narzędzia genhtml (w projekcie lcov), by wygenerować raport, który można wyświetlić w przeglądarce:

genhtml --output genhtml "$(bazel info output_path)/_coverage/_coverage_report.dat"

Pamiętaj, że genhtml odczytuje też kod źródłowy, by opisać w tych plikach brakujące pokrycie. Aby to się udało, obiekt genhtml musi zostać uruchomiony w katalogu głównym projektu bazy danych.

Aby wyświetlić wynik, po prostu otwórz plik index.html utworzony w katalogu genhtml dowolnej przeglądarki.

Więcej informacji o narzędziu genhtml oraz formacie lcov znajdziesz w artykule na temat projektu LCOV.

Zdalne

Wykonywanie testów zdalnych wymaga obecnie pewnego zastrzeżenia:

  • Działanie kombinacji raportu nie może jeszcze działać zdalnie. Bazel nie uwzględnia plików wyjściowych pokrycia w wykresie (zobacz ten problem) i dlatego nie może prawidłowo ich traktować jako danych wejściowych. działania. Aby obejść ten problem, użyj elementu --strategy=CoverageReport=local.
    • Uwaga: jeśli usługa Bazel jest skonfigurowana tak, aby testować local,remote, może być konieczne określenie czegoś w rodzaju --strategy=CoverageReport=local,remote. Jest to spowodowane tym, jak Bazel stosuje strategie.
  • Flagi --remote_download_minimal i inne podobne flagi nie mogą być używane w wyniku pierwszego.
  • Jeśli testy zostały wcześniej zapisane w pamięci podręcznej, Bazel nie może obecnie tworzyć informacji o zasięgu. Aby obejść ten problem, możesz ustawić --nocache_test_results na potrzeby testów pokrycia, ale wiąże się to z dużym kosztem w czasie testowania.
  • --experimental_split_coverage_postprocessing oraz --experimental_fetch_all_coverage_outputs
    • Zazwyczaj pokrycie jest uruchamiane w ramach działania testowego, więc domyślnie nie pobieramy go w całości jako dane wyjściowe zdalnego wykonywania. Te flagi zastępują domyślne i otrzymują dane o zasięgu. Aby dowiedzieć się więcej, przeczytaj ten problem.

Konfiguracja dla konkretnego języka

Java

Java powinna od razu działać z domyślną konfiguracją. Bazel Toolchains zawierają wszystkie elementy niezbędne do zdalnego wykonywania, w tym JUnit.

Python

Wymagania wstępne

Korzystanie z zasięgu Pythona wymaga spełnienia pewnych wymagań wstępnych:

Wykorzystanie zmodyfikowanego pokrycia.py

Aby to zrobić, użyj reguły rules_python. Dzięki niemu możesz użyć pliku requirements.txt. Wymagania wymienione w pliku będą wtedy tworzone jako docelowe bazy danych przy użyciu atrybutu 101}pip_install regułę repozytorium.

requirements.txt musi zawierać ten wpis:

git+https://github.com/ulfjack/coveragepy.git@lcov-support

Plików rules_python, pip_install i requirements.txt należy używać w pliku WORKSPACE jako:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "rules_python",
    url = "https://github.com/bazelbuild/rules_python/releases/download/0.5.0/rules_python-0.5.0.tar.gz",
    sha256 = "cd6730ed53a002c56ce4e2f396ba3b3be262fd7cb68339f0377a45e8227fe332",
)

load("@rules_python//python:pip.bzl", "pip_install")

pip_install(
   name = "python_deps",
   requirements = "//:requirements.txt",
)

Aby sprawdzać, czy żądania testowe są spełnione, możesz wymagać tego ustawienia, ustawiając w plikach BUILD ten parametr:

load("@python_deps//:requirements.bzl", "entry_point")

alias(
    name = "python_coverage_tools",
    actual = entry_point("coverage"),
)

py_test(
    name = "test",
    srcs = ["test.py"],
    env = {
        "PYTHON_COVERAGE": "$(location :python_coverage_tools)",
    },
    deps = [
        ":main",
        ":python_coverage_tools",
    ],
)