Szukaj
Logowanie
Nawigacja
Wersja RSS
Kto jest online
Ankieta Ile wynosi pokrycie kodu testami (code coverage) w twoim projekcie? został zamknięta, każdy może sprawdzić wyniki. I z mojej strony pasuje kilka słów podsumowania, aby głos ludu nie został pominięty ;-)
Najbardziej zmartwiły mnie dwie odpowiedzi, a w sumie to duża ilość głosów na nie oddanych. Chodzi mi mianowicie o nie wiem o co chodzi oraz nie piszę testów. Sumarycznie daje to 43% ankietujących nie testuje swoich aplikacji. Możliwe, że część, którzy zagłosowali na nie wiem o co chodzi pisze testy, ale najwyraźniej nie jest to rozwiązanie systemowe w ich projektach / firmach. Robią to po ktoś powiedział, że tak powinno się robić. Niedobrze!
Pisanie testów i monitorowanie ile kodu aplikacji jest pokrytych za pomocą testów (czyli code coverage) to powinna być normalna praktyka w projekcie, jak oddychanie. Zaczynamy nowy projekt i od razu ustawiamy Ciągłą Integrację (CI), przygotowujemy task, który co tydzień będzie dostarczał całemu zespołowi raport o Pokryciu Kodu (CC) (trochę niefortunne sformułowanie ;-).
Z powyższego widać, że ten obszar świadomości programistycznej w naszym JavaLandzie ciągle jest mocno w tyle za światowymi trendami. Jedyna pozytywna rzecz, to może być tylko lepiej!
I jeszcze jedna rzecz, cztery głosy oddane na 100% kodu trochę mnie zaskoczyły, rozumiem, że dążymy do doskonałości, ale w tym przypadku to trochę już paranoja, należy mieć umiar we wszystkim. Myślę, że 60% - 80% to jest wynik zadowalający w większości projektów, z wyjątkiem tych kilku, gdzie pokrycie testami ma być na poziomie 95% (podnosimy średnią wymaganą). Ale 100%?
Dzisiaj nowa ankieta, która pozostaje dalej w kwestiach związanych z jakością produkowanego kodu (tak aby podnosić globalną świadomość programistyczną w JavaLandzie ;-)
Pozdrawiam
--
Łukasz
http://www.lenart.org.pl/
- Łukasz Lenart's blog
- Login or register to post comments
- 1616 odsłon
Comments
Warto jest miec cel... niekoniecznie warto go osiagnac.
Absolutnie zgadzam sie z koziolkiem.
Problem jest znacznie szerszej i filozoficznej natury. Chodzi o mierzenie jakosci kodu... Czy kod o 100% pokryciu jest kodem lepszej jakosci, niz ten, ktory ma 67.5% ? Do tego dochodzi roznorodnosc pokryc kodu:
- pokrycie funkcji
- pokrycie sciezek
- pokrycie instrukcji
- ... (odsylam do Wikipedii, coby zobaczyc w czym rzecz)
Do tego dochodzi koszt. Jakim kosztem mozna osiagnac 100% pokrycie kodu? Do tego moznaby dolozyc testowanie kodu odpowiedzialnego za interfejs graficzny; mozna jeszcze dorzucic testowanie geterow i setterow,... Okazuje sie, ze nie ma sie co zabijac. Warto mierzyc, aby podejmowac decyzje, ktore sa poparte lepszymi informacjami. Decyzja o nie dazeniu do 100% pokrycia kody odpowiedzialnego za UI jest jak najbardziej wartosciowa i normalna - sa inne metody i metodyki... Po co spedzic kolejnych kilka tyg. (i kolejnych kilka tys PLN) na dazeniu do 100% pokrycia, ktore i tak nie daje 100% pewnosci deweloperom, ergo ich menadzerom, bo developerzy hakowali po 12h/dobe pompujac sie kawa, zamiast wyslac interfejs do powiedzmy 10 testerow od 'uzywalnosci' softu.
Do tego dochodzi rowniez cena utrzymania testow ladnych i zgrabnych kontra utrzymania misz-maszu napisanego w celu osiagniecia 100% pokrycia. Wartosc testow jest w tym, ze kazdy moze je przeczytac, w miare szybko zrozumiec i nabrac pewnosci co do kodu, miec deske ratunku, ktora pozawala uruchomic testy po duzych zmianach i zeby szybko sprawdzic, czy nie popsulismy czegos, co wszesniej dzialalo i zostalo przetestowane.
Nalezy pamietac, ze testy nie sa tylko i wylacznie po to, aby udowodnic, ze kod jest w 100% przetestowany. Mozna miec 100% pokrycie bez nawet jednego porownania danych oczekiwanych z danymi aktualnymi.
Najlepszym i najbardziej realnym podejsciem jest osiaganie jak najwiekszego pokrycia, w najbardziej skomplikowanych klasach i metodach, ktore maja do czynienia z logika biznesowa. Polecam lekture nt. Cylometric Complexity oraz Javove narzedzie Crap4j.
Dobry opis zagadnien ryzyka utrzymania kodu, wzgledem pokrycia i skomplikowania.
Brak poprawnej odpowiedzi
Łukasz, w tej nowej ankiecie brak jest "jedynej poprawnej" odpowiedzi :)
Tzn są dwie w miarę pozytywne (2 ostatnie), ale nie ma takiej, jakiej bym oczekiwał od członków dobrze prowadzonych (prowadzących się) zespołów - mianowicie: jest, zespół ciągle dba o brak zepsutych buildów.
CI pochodzi z kręgów agile'owych (konkretnie XP) a tu główny nacisk kładziemy na zespół. To on jest właścicielem CI i to jemu CI służy. Więc kto zewnętrzny miałby tu kogoś/zespół rozliczać? Albo dlaczego ktoś miałby być karany? Jeśli cały zespół o to dba i mu zależy, to doprowadzenie do takiej sytuacji jest wystarczającym wstydem, że nic więcej winnemu robić nie trzeba.
Pozdrowienia z AgileLandu :)
Paweł Lipiński
W sumie to jeśli zespół
W sumie to jeśli zespół Agile sam się rozlicza to ostatnia odpowiedź jest ok, tak samo karą jest wstyd przed resztą zespołu za zepsuty build. Wszystko się zgadza, kwestia interpretacji ;-)
Pozdrawiam
--
Łukasz
Zboczenńcy
100% to marzenie. Można je zrealizować, ale trzeba mieć czas i poczucie humoru:
http://koziolekweb.pl/2009/03/22/testowanie-wyjatkow-w-prywatnych-metodach/
Cobertura mówi 100%. Swoją droga nie pisanie testów jest zazwyczaj zasługą pierwszego poganiacza, który "nie płaci ci za pisanie nadmiarowego kodu". Ciekawa ankieta... daje do myślenia.