Pytanie do tych którzy zetknęli się z ekskluzja pokrycia w testach

Jak się odpala normalny coverage (czy to line coverage, branch coverage, path coverage czy jeszcze inne), to schemat jest ten sam: jeśli kawałek kodu został uruchomiony podczas testu - to jest oznaczany jako covered.

Ale np. w PhpUnit i paru innych frameworkach do testów, jest tak funkcja jak ekskluzja pokrycia. I to działa tak, że można adnotacją albo configiem, per test albo per suite oznaczyć listę klas "do pokrycia". I to działa w ten sposób, że te klasy które nie są oznaczone jako "do pokrycia" mają ustawione na sztywno zawsze 0% covered; a te które są oznaczone jako "do pokrycia", to mają tam coverege gdzie faktycznie kod się odpalił.

Oczywiście, to jest i tak marna metoda sprawdzania przetestowania kodu - wiadomo ze TDD jest lepsze, a coverege nie jest żadnym (przynajmniej dla mnie) wyznacznikiem tego jak coś jest przetestowane. To się rozumie samo przez się, nie o tym jest wątek.

Wątek, chciałem zadać z innego powodu:

• z jednej strony to jest fajne, bo zawężając taką ekslusją niwelujemy przypadkowe covergae (że jakaś klasa przy okazji jest odpalona, ale wcale nie jest przetestowana).
• z drugiej strony, co z klasami i funkcjami wewnętrznymi, które są zaenkapsulowane w jakimś rozwiązaniu:
  • Albo ich nie oznaczamy, i one są wiecznie ustawione jako uncovered
  • Albo je oznaczamy, tylko wtedy łamiemy enkapsulację i chcąc potem zmienić kawałek kodu trzeba pamiętać (albo nie :D) żeby zmienić tą ekslusję.

Czy to narzędzie jest warte łamania takiej enkapsulacji?

KamilAdam napisał(a):

Może offtop już w pierwszym poście, ale co to znaczy

jakaś klasa przy okazji jest odpalona, ale wcale nie jest przetestowana

Chodzi o to że jej funkcje zostały wywołane podczas działania testu, ale nie zostały one należycie (albo wcale) przetestowane. Tzn, zostały uruchomione przy okazji, ale gdyby je zepsuć/usunąć, to żaden test by nie sfailował.

Może offtop już w pierwszym poście, ale co to znaczy

jakaś klasa przy okazji jest odpalona, ale wcale nie jest przetestowana

?

To chyba się nadaje do tej proponowanej kategorii o polszczyźnie. Nawet Google mi nie zwraca żadnego wyniku dla takiego słowa jak "ekslusja".

W jakich przypadkach widzisz sens takiego ficzera? Jedyne co mi przychodzi do głowy to wykluczenie z coverage kodu generowanego lub wklejonego (np. sqlite.c), żeby coverage był bardziej miarodajny.

Nigdy nie używam tej możliwości ani do klas/funkcji wewnętrznych, ani do czegoś przez testy odpalane.
Oznaczam w ten sposób jedynie ten kod, którego w testach nie odpalam w ogóle.

Słuchaj @Riddle, albo blanty albo programowanie, nie jedno i drugie na raz. Nie wiem o co pytasz więc tylko napiszę dlaczego wyłącza się pewien kod z liczenia pokrycia.

W niekórych koporacjach architekci lub menedżerowie zespołów developerskich wróciwszy dopiero co z konferencji uznali, że mając wysokie pokrycie testami będą mieli fajne osiągnięcie na podsumowaniu rocznym, bo ładna stronka z zielonymi lampkami i wysmarowanym na grubo 99% wygląda całkiem kozacko. Więc zaczęli wymagać jakiegoś absurdalnego pokrycia testami jednostkowymi (tego pojęcia nauczyli się na konferencji) na poziomie 95% i więcej. Osiąganie takiego pokrycia jest często niemożliwe a innym razem nie praktyczne, bo nagle się okazuje, że mockujesz znacznie więcej niż się spodziewałeś (I/O, konteksty bazy, UI itp.) to jeszcze się okazuje, że musiałbyś zacząć testować settery/gettery i inny taki g**no kod, który skleja Ci różne kawałki a sam nie zawiera żadnego przetwarzania więc nie warto go testować.

I po to właśnie wyłącza się taki g**no kod plus nietestowalne danym typem testów fragmenty z mierzenia pokrycia, żeby przełożony mógł sobie popatrzeć na mrugającą na zielono stronkę na koniec roku.

several napisał(a):

Słuchaj @Riddle, albo blanty albo programowanie, nie jedno i drugie na raz. Nie wiem o co pytasz więc tylko napiszę dlaczego "wyłącza" się pewien kod z liczenia pokrycia.

W niekórych koporacjach architekci lub menedżerowie zespołów developerskich wróciwszy dopiero co z konferencji uznali, że mając wysokie pokrycie testami będą mieli fajne osiągnięcie na podsumowaniu rocznym, bo ładna stronka z zielonymi lampkami i wysmarowanym na grubo 99% wygląda całkiem kozacko. Więc zaczęli wymagać jakiegoś absurdalnego pokrycia testami jednostkowymi (tego pojęcia nauczyli się na konferencji) na poziomie 95% i więcej. Osiąganie takiego pokrycia jest często niemożliwe a innym razem nie praktyczne, bo nagle się okazuje, że mockujesz znacznie więcej niż się spodziewałeś (I/O, konteksty bazy, UI itp.) to jeszcze się okazuje, że musiałbyś zacząć testować settery/gettery i inny taki g**no kod, który skleja Ci różne kawałki a sam nie zawiera żadnego przetwarzania więc nie warto go testować.

I po to właśnie wyłącza się taki g**no kod plus nietestowalne danym typem testów fragmenty z mierzenia pokrycia, żeby przełożony mógł sobie popatrzeć na mrugającą na zielono stronkę na koniec roku.

No, zgadzam się. Piszesz off-topic, ale zgadzam się.

Ty mówisz, o "wyłączeniu z pokrycia" w taki sposób, że coś nie jest pokryte, ale też się nie liczy do ilość linii, więc wyłączając taki kod z pokrycia coverge nam rośnie. I zgadzam się z tym, że to jest bardzo bullshit - nie chcę czegoś takiego.

Ja mówię o takim wyłączeniu z pokrycia że kod nie jest pokryty, ale jego liniie NADAL SIĘ LICZĄ do proporcji, więc wyłączając taki kod, coverge nam spada. I w raporcie coverge'a one są nadal pokazane jako niepokryte.

Innymi słowy, Ty mówisz o tym jak można sobie strzelić w stopę i przekłamać coverege, ja mówię o narzędziu do niwelowania przypadkowego coverege'a i niwelowaniu przekłamań.

Sens tego jest tylko wtedy gdy ktoś testuje zachowanie komponentów za pomocą testów systemowych / E2E / integracyjnych (zwał jak zwał).

Jeżeli odpalam taki test, mogę zaznaczyć, że intencją jest tylko przetestowanie komponentu X i wykluczyć komponenty A i B. Dzięki temu testy, których intencją jest przetestowanie komponentu X, nie nabijają sztucznie pokrycia dla komponentów A i B.

Odpowiadając na pytanie: Pokrycie kodu jest tak marną i słabą metryką, że naruszanie enkapsulacji i plątanie kodu testów z kodem produkcyjnym nie jest w ogóle tego warte.

Jak już liczysz pokrycie, to powinieneś wiedzieć po co i dlaczego twoja metryka ma nie uwzględniać jakiegoś tam kawałka kodu. Moja opinia o wskaźnikach pokrycia kodu jest taka, że jedynym jej praktycznym zastosowaniem jest bycie fap-materiałem dla różnych szczebli software development governance.

piotrpo napisał(a):

Jak już liczysz pokrycie, to powinieneś wiedzieć po co i dlaczego twoja metryka ma nie uwzględniać jakiegoś tam kawałka kodu.

No i wiem.

Dlatego, że wiem że te kawałki które chce wykluczyć i tak nie są przetestowane, i to pokrycie będzie kłamliwe.

piotrpo napisał(a):

Moja opinia o wskaźnikach pokrycia kodu jest taka, że jedynym jej praktycznym zastosowaniem jest bycie fap-materiałem dla różnych szczebli software development governance.

Jeśli nie umiesz jej interpretować to tak - masz rację.

Ale jeśli umiesz, i wiesz czym coverage jest i nie jest, to to może być pomocne narzedzie. Pod warunkiem że wiesz jak go używać i nie wpadasz w popularne pułapki (jak przekonanie że pokryty kod to przetestowany kod).