Czy powinniśmy wykluczyć kod do analizy zasięgu kodu?

Pracuję nad kilkoma aplikacjami, głównie starszymi. Obecnie ich zasięg kodu jest dość niski: zwykle od 10 do 50%.

Od kilku tygodni prowadzimy cykliczne dyskusje z zespołami z Bangalore (główna część rozwoju jest offshore w Indiach) na temat wyłączeń pakietów lub klas dla Cobertura (nasze narzędzie do obsługi kodu, nawet jeśli obecnie migrujemy do JaCoCo).

Ich punkt widzenia jest następujący: ponieważ nie będą pisać testów jednostkowych na niektórych warstwach aplikacji (1) , warstwy te należy po prostu wykluczyć z zakresu pokrycia kodu. Innymi słowy, chcą ograniczyć miarę pokrycia kodu do kodu, który jest testowany lub powinien zostać przetestowany .

Ponadto, gdy pracują nad testem jednostkowym dla złożonej klasy, korzyści - wyłącznie pod względem zasięgu kodu - pozostaną niezauważone ze względu na dużą aplikację. Ograniczenie zakresu kodu sprawi, że tego rodzaju wysiłki będą bardziej widoczne ...

Interesujące to podejście polega na tym, że będziemy mieli miarę pokrycia kodu, która wskazuje bieżący status części aplikacji, którą uważamy za testowalną .

Z mojego punktu widzenia uważam jednak, że w jakiś sposób oszukujemy liczby. To rozwiązanie jest łatwym sposobem na osiągnięcie wyższego poziomu pokrycia kodu bez żadnego wysiłku. Kolejną kwestią, która mnie niepokoi, są następujące: jeśli pokażemy wzrost zasięgu z tygodnia na tydzień, jak możemy stwierdzić, czy ta dobra wiadomość wynika z dobrej pracy programistów, czy po prostu z nowych wykluczeń?

Ponadto nie będziemy w stanie dokładnie wiedzieć, co jest brane pod uwagę w ramach pomiaru zasięgu kodu. Na przykład, jeśli mam 10 000 wierszy aplikacji kodu z 40% pokryciem kodu, mogę odliczyć, że 40% mojej bazy kodu jest testowane (2) . Ale co się stanie, jeśli ustawimy wykluczenia? Jeśli pokrycie kodu wynosi teraz 60%, co mogę dokładnie odliczyć? Czy 60% mojej „ważnej” bazy kodu jest testowane? Jak mogę

Jeśli o mnie chodzi, wolę zachować „rzeczywistą” wartość pokrycia kodu, nawet jeśli nie możemy być z tego zadowoleni. Ponadto, dzięki Sonarowi, możemy łatwo nawigować w naszej bazie kodu i wiedzieć, dla dowolnego modułu / pakietu / klasy, własny zasięg kodu. Ale oczywiście globalny zasięg kodu będzie nadal niski.

Jakie jest twoje zdanie na ten temat? Jak sobie radzisz przy swoich projektach?

Dzięki.

(1) Te warstwy są ogólnie powiązane z komponentami bean UI / Java itp.

(2) Wiem, że to nieprawda. W rzeczywistości oznacza to tylko, że 40% mojej bazy kodu

Ogólnie wykluczam kod generowany automatycznie, na przykład klientów WCF generowanych przez Visual Studio. Zazwyczaj jest tam wiele linii kodu i nigdy nie będziemy ich testować. To sprawia, że ​​bardzo demoralizujące jest zwiększenie testowania dużej części kodu w innym miejscu i zwiększenie zasięgu kodu tylko o 0,1%.

Wykluczę także interakcje między warstwami danych, o ile zespół będzie mógł z całą pewnością stwierdzić, że ta warstwa jest tak cienka, jak to tylko możliwe. Chociaż można argumentować, że jeśli warstwa jest cienka, nie będzie miała wielkiego efektu, pozostawia wiele elementów w raporcie pokrycia z 0% względem nich, więc niekoniecznie zauważamy te, których potrzebujemy naprawdę się martwić. Warstwę interfejsu użytkownika można argumentować w podobny sposób, w zależności od używanego frameworka.

Ale jako kontrapunkt wykluczę również same testy jednostkowe. Powinny zawsze mieć ~ 100% pokrycia i stanowią duży procent podstawy kodu, przekrzywiając liczby niebezpiecznie w górę.

Dobre pytanie. Zasadniczo wykluczam kod z pokrycia z kilku powodów, np. Jest to:

• wygenerowane
• starsza wersja (nie jest już aktualizowana)
• oto nadchodzi: niektóre warstwy, nie zamierzam testować

Dlaczego ostatni punkt? Myślę, że dobrą praktyką jest skupianie się na rzeczach, na których mi zależy, a jednocześnie tłumienie rozproszenia. Jeśli nie zamierzasz testować warstwy interfejsu użytkownika, dlaczego warto wziąć to pod uwagę - odwróciłoby to uwagę tylko od ważnej części oprogramowania - logiki biznesowej.

ALE:

1. Powinieneś mieć dobry powód, dlaczego w ogóle wykluczać określoną warstwę z testów jednostkowych (mogą być pytania - od szefa, kolegów z drużyny, prasy ;-)
2. Jeśli chcesz, aby przetestowali te warstwy, powinieneś uwzględnić je w statystykach, aby pokazać całemu zespołowi, każdego dnia, że ​​jest to ważne i należy to zrobić.

Wreszcie: nie bierz liczb zbyt poważnie. 30% pokrycia może udowodnić, że oprogramowanie jest solidne, gdy jest to jego zasadnicza część.

Zgadzam się z tobą i uwzględniam cały odpowiedni kod w metodzie pokrycia kodu (i ogólnie Sonar). Nawet jeśli nie planujesz testować niektórych części kodu (w przewidywalnej przyszłości), wskaźniki powinny odzwierciedlać rzeczywisty stan. To zmusza cię do posiadania ważnego powodu, aby nie pisać testów dla znacznej części bazy kodu. W końcu (gdy inne, ważniejsze części kodu zostaną już uwzględnione) możesz ponownie rozważyć lub wybrać inny sposób, aby wyeliminować ten dysonans - np. Przez ponowne przetworzenie danego kodu w celu umożliwienia jego przetestowania lub migrację całej logiki z niego do inna, testowalna część bazy kodu, a nawet całkowite wyeliminowanie całej warstwy (jeśli warstwa nie jest warta przetestowania, czy ma wystarczająco dobry powód, by istnieć?)

W moich bieżących projektach uwzględniamy również cały kod w metrykach, z jednym wyjątkiem: generowany kod, generujący mnóstwo ostrzeżeń z analizy statycznej. Ponieważ ten kod zazwyczaj składa się z ogromnych klas POD bez żadnej logiki, i tak nie ma nic do przetestowania.

Teraz nie znam się zbyt dobrze na narzędziach do pokrywania kodu, których używasz, ani nie znam fasoli Java, ale z tego, co mówisz, są one związane z interfejsem użytkownika.

Przy mojej ograniczonej wiedzy mam to do powiedzenia:

1. Nie pozwól, aby liczby przy pomocy jakichkolwiek narzędzi testowych utrudniały przeprowadzanie testów.
2. Jeśli klasy są złożone i nie można ich testować jednostkowo, zawsze dobrym pomysłem jest ponowne ich uwzględnienie w bardziej kompaktowe i testowalne klasy. Będzie to wymagało dużego wysiłku i poświęcenia, ale na dłuższą metę zapłaci.
3. Testowanie komponentów interfejsu użytkownika może być trudne, ale nadal można przetestować funkcję wykonywaną przez te komponenty.
4. Jeśli wykonujesz projekt internetowy, możesz użyć QUnit do jednostkowego przetestowania całego kodu po stronie klienta.

Podsumowując, należy pamiętać, że pokrycie kodu to tylko liczba, a wysoki zakres kodu nie oznacza dobrych testów. Skoncentruj się na tym, aby biblioteki podstawowe były bardziej niezawodne i testowalne, niż dążyć do wyższego odsetka.

Niektóre wyłączenia mają sens (kod płyty kotła, który nie ma rzeczywistego wpływu ani potencjalnego wpływu na prawidłowe funkcjonowanie projektu). Nawet wciąż zbieranie pokrycia kodu jako metryki jest bezcelowe, ponieważ i tak nie mówi nic użytecznego. 100% pokrycia kodu nie jest prawdziwym celem, a niskie liczby pokrycia również mogą nie być złe w zależności od projektu, możliwe, że 20-30% pokrycia kodu obejmuje wszystko, co warto przetestować. pokrycie kodu informuje tylko o X% twojego kodu, który potencjalnie warto pokryć, to jakiś test o nieznanej jakości.

Sugeruję zgłoszenie zestawu danych dla każdej warstwy kodu. Wskaźniki te powinny obejmować informacje o rozmiarze (np. LoC, liczba bibliotek, liczba klas lub metod itp.), Informacje o testowaniu (np. Zasięg) oraz informacje o błędach (np. Częstość wyszukiwania i napraw).

Wykluczone warstwy będą miały 0% pokrycia, a testowane obszary będą miały wspomniane 60% pokrycia. Informacje o rozmiarze pozwolą ludziom zrozumieć, ile jest testowane lub niesprawdzone. Informacje o błędzie poinformują cię, czy możesz tworzyć testy dla wykluczonych warstw i czy istniejące testy działają.

Organizacjom oprogramowania łatwo jest zbyt skoncentrować się na czystości danych. Nie tworzymy wskaźników, tworzymy dobre oprogramowanie. Metryka, która pomaga terminowo dostarczać wysokiej jakości oprogramowanie, jest najbardziej uczciwą i czystą metryką.