Zespół z dumą zgłasza 95% pokrycia kodu, a następnie wysyła błąd w wierszu, który został „objęty”. To nie jest sprzeczność. Pokrycie odpowiada na jedno wąskie pytanie: czy testy wykonały ten kod? To, czy sprawdzili wynik, to zupełnie inna kwestia.

Użyliśmy Pythona z pokryciem.py 7.17 i pytestem 9.2. Wszystkie poniższe liczby i raporty pochodzą z naszego własnego badania. Idee mają zastosowanie w każdym języku.

Co to jest pokrycie kodu?

Pokrycie kodu to procent kodu, który działa podczas działania testów automatycznych. Narzędzie rejestruje, które linie i opcjonalnie które gałęzie zostały wykonane, a następnie raportuje, co zostało pominięte.

Najbardziej przydatne jest to w odwrotnej kolejności. Niski zasięg na danym obszarze z całą pewnością mówi, że testy go nie sprawdzają. Wysoki zasięg mówi znacznie mniej.

Rodzaje pokrycia

Każdy poziom jest bardziej rygorystyczny niż ten powyżej. Większość zespołów monitoruje zasięg linii i gałęzi. Pokrycie warunków i MC/DC pojawiają się w standardach lotniczych i motoryzacyjnych, gdzie specjalizuje się wsparcie narzędziowe.

Kod, który zmierzyliśmy

def shipping_fee(total, is_member, express=False):
    if total < 0:
        raise ValueError("total cannot be negative")
    fee = 0 if total >= 1000 else 50
    if is_member:
        fee = max(fee - 25, 0)
    if express:
        fee += 100
    return fee

Nasz pierwszy plik testowy zawierał dwa testy:

def test_regular_order():
    assert shipping_fee(500, False) == 50

def test_member_express():
    assert shipping_fee(500, True, express=True) == 125

Uruchomiliśmy go z włączonym pomiarem gałęzi:

coverage run --branch -m pytest test_shipping.py
coverage report -m

Czytanie raportu

Name          Stmts   Miss Branch BrPart  Cover   Missing
---------------------------------------------------------
shipping.py       9      1      6      1    87%   3

• Stmts 9, Miss 1: dziewięć wykonywalnych instrukcji, jedna nigdy nie została uruchomiona.
• Oddział 6, BrCzęść 1: trzy if decyzje dają sześć możliwych wyników. Jedna decyzja zawsze szła tylko w jedną stronę.
• Brakujące 3: linia 3, raise ValueError, nigdy nie została uruchomiona. Żaden test nie dał wyniku negatywnego.

Poprawka polega na sprawdzeniu ścieżki błędu. Dodaliśmy także test dla dużego zamówienia:

def test_free_over_1000():
    assert shipping_fee(1000, False) == 0

def test_negative_total():
    with pytest.raises(ValueError):
        shipping_fee(-1, False)

W przypadku obu plików raport pokazywał 100% i nie brakowało żadnych linii ani częściowych rozgałęzień. Ścieżki błędów to klasyczne metody pokrycia luk, dlatego też testy pod kątem nieprawidłowych danych wejściowych, zaprojektowane przy użyciu technik takich jak podział przez równoważność, tak dobrze się z nimi łączą.

Co ukrył raport

Spójrz jeszcze raz na pierwszy raport. Mówi, że brakuje tylko linii 3. Jednak w obu pierwszych testach wykorzystano łącznie 500 sztuk, więc zasada bezpłatnej wysyłki dla zamówień na kwotę 1000 lub więcej nie była nigdy testowana i w raporcie nie została ona oznaczona.

Powodem jest to, że fee = 0 if total >= 1000 else 50 znajduje się w jednej linii. zasięg.py mierzy rozgałęzienia między wierszami, więc wyrażenie warunkowe w pojedynczej linii liczy się jako jedna wykonana instrukcja. Gdyby ta reguła zawierała błąd, taki jak > zamiast >=, pierwszy zestaw nadal pokazywałby 87% bez żadnej wskazówki. Testy samej granicy, jak opisano w analizie wartości granic , są tym, co ją wyłapuje.

Ubezpieczenie 100% bez żadnych kontroli

Następnie napisaliśmy celowo słaby test, który wywołuje każdą ścieżkę, ale niczego nie stwierdza:

def test_runs_everything_but_checks_nothing():
    shipping_fee(500, True, express=True)
    shipping_fee(1000, False)
    shipping_fee(500, False)
    try:
        shipping_fee(-1, False)
    except ValueError:
        pass

shipping.py       9      0      6      0   100%

Osiągnięto 100% zasięgu linii i odgałęzień. Funkcja może zwrócić dowolną liczbę, a test i tak zakończy się pomyślnie. Jest to podstawowy limit pokrycia: mierzy wykonanie, a nie weryfikację.

Aby zmierzyć, czy testy faktycznie wyłapują błędy, użyj testowania mutacji. Narzędzie takie jak mutmut dla Pythona, PIT dla Java lub Stryker dla JavaScript wprowadza niewielkie zmiany w kodzie, takie jak zamiana >= na > i sprawdza, czy test się nie powiedzie. Nasz test bez potwierdzenia pozwoliłby przetrwać każdej mutacji.

Jaki cel wyznaczyć

Nie ma uniwersalnej liczby. Praktyczne wskazówki:

• Nie goń za 100%. Ostatnie kilka procent często oznacza testowanie trywialnego kodu lub pisanie testów, które po prostu dotykają granic.
• Wiele zespołów dąży ogólnie do około 70–85%, przy wyższych oczekiwaniach dotyczących podstawowej logiki biznesowej.
• Obserwuj trend, a nie liczbę. Zasięg spadający z każdą publikacją jest sygnałem ostrzegawczym.
• Wymagaj uwzględnienia nowego kodu w żądaniach ściągnięcia zamiast wymuszania całego starego kodu na raz.
• Wyklucz to, co nie ma znaczenia, np. wygenerowany kod, stosując jasne zasady.

Obowiązuje prawo Goodharta: kiedy środek staje się celem, przestaje być dobrym środkiem. Twarde cele zachęcają do testów, takich jak nasz przykład bez twierdzeń.

Narzędzia według języka

Zasięg w CI

Uruchom analizę w ramach potoku CI i opublikuj raport, aby recenzenci mogli zobaczyć, które nowe linie nie zostały przetestowane. W przypadku cover.py coverage report --fail-under=80 kompilacja poniżej progu kończy się niepowodzeniem. Zachowaj skromny próg i połącz go z regułą dotyczącą nowego kodu, aby pojedynczy duży, starszy plik nie blokował wszystkich zmian.

Poza zasięgiem: lepsze pytania do zadawania

• Czy testy obejmują ryzykowne, często zmieniane części kodu?
• Czy testowane są granice i ścieżki błędów, a nie tylko szczęśliwa ścieżka?
• Czy test zakończyłby się niepowodzeniem, gdyby ta linia była błędna?
• Czy testy są wystarczająco szybkie i stabilne, aby można je było uruchomić przy każdej zmianie?

Należą one do dowolnej strategii testowej. Zasięg pomaga odpowiedzieć tylko na to pierwsze.

Wykluczanie kodu i czytanie raportów HTML

Niektórych kodów nie warto testować bezpośrednio, na przykład pomocników debugowania lub bloków uruchamianych tylko wtedy, gdy skrypt jest uruchamiany ręcznie. cover.py pozwala wykluczyć linie z komentarzem:

if __name__ == "__main__":  # pragma: no cover
    main()

Możesz także ustawić wykluczenia i foldery źródłowe do pomiaru w konfiguracji, na przykład w pyproject.toml:

[tool.coverage.run]
branch = true
source = ["shop"]

[tool.coverage.report]
show_missing = true
exclude_also = ["if TYPE_CHECKING:"]

Używaj wykluczeń oszczędnie i przeglądaj je jak kod. Każda z nich jest decyzją, że niektóre linie nigdy nie zostaną sprawdzone. Wykluczenie trudnego do przetestowania modułu obsługi błędów tylko po to, aby podnieść liczbę, mija się z celem.

W codziennej pracy raport HTML jest bardziej przydatny niż tabela terminali. Uruchom coverage html i otwórz htmlcov/index.html. Każdy plik jest pokazany z wykonanymi liniami na zielono, brakującymi liniami na czerwono i częściowymi gałęziami na żółto, dzięki czemu można na pierwszy rzut oka zobaczyć, który if nigdy nie poszedł inną ścieżką. Wielu redaktorów może także pokazywać pokrycie na marginesie, co sprawia, że ​​luki są widoczne podczas pisania kodu, a nie później.

Pokrycie przed refaktoryzacją

Pokrycie to także kontrola bezpieczeństwa przed refaktoryzacją. Jeśli planujesz restrukturyzację modułu, najpierw przejrzyj jego raport. Na czerwonych obszarach nie ma testów ostrzegających o zmianie zachowania, dlatego przed rozpoczęciem dodaj testy charakteryzujące, które wychwytują bieżące zachowanie. Używany w ten sposób zasięg przestaje być celem, a staje się praktycznym narzędziem planowania.

Ten sam raport pomaga, gdy błąd przedostanie się do środowiska produkcyjnego. Znajdź linię, w której mieszkał błąd i sprawdź, czy przeprowadził go jakiś test. Jeśli nie, znalazłeś lukę, którą warto zamknąć. Jeśli test rzeczywiście go uruchomił, problemem jest słaba asercja, a dokładnie taką sytuację pokazał nasz przykład bez asercji. Obie odpowiedzi mówią, jak ulepszyć pakiet.

Podsumowanie

Pokrycie kodu to latarka, a nie ocena. Użyj pokrycia gałęzi, aby znaleźć kod, którego nie dotyka żaden test, zwłaszcza obsługę błędów, a następnie napisz testy, które dokonują prawdziwych asercji. Jeśli pamiętasz jeden wynik z naszego testu, niech to będzie ten: 100% pokrycia zostało osiągnięte w teście, który niczego nie sprawdził.

Najczęstsze pytania

Ucz się dalej