Słuchajcie, wiecie jak to jest z tymi obietnicami. Wypije się za dużo kakałka, nie wyśpi, a potem obiecujesz ludziom, że napiszesz konkretny artykuł na specyficzny temat. No i tak właśnie to ten, napisałem go. Obietnic się dotrzymuje, koniec i kropka ;). Tak jak obiecałem, będzie to sposób przesłania raportu o pokryciu kodu testami do serwera SonarQube. Miałem trochę na głowię – zagraniczna delegacja, rozwój firmy – więc chwile to zajęło, ale mieszczę się jeszcze w terminie ;). Chcąc podążać jeden do j...
Pisząc unit testy chcielibyśmy wiedzieć, czy robimy to wystarczająco dobrze i czy dodajemy w ten sposób wartość do projektu. Informacja ta jest potrzebna programistom, aby mogli doskonalić swój warsztat i ułatwiać pracę zespołowi. Korzystają z niej również managerowie planując zadania, skład zespołu itp. Najczęściej wykorzystywaną metryką jest tutaj test coverage, jednak niesie ona jedynie ograniczoną informację. Ważne są również miary empiryczne, które ciężko przedstawić w formie liczbowej. Na począt...
Sztuka programowania 2389 dni, 23 godziny, 15 minut temu 94 źrodło rozwiń
Opublikowano We wpisie o pokryciu kodu (Code Coverage) napisałem: Należy pamiętać, że to są narzędzia dla programisty Co przez to rozumiem? Code Coverage nie może być używany przez kierownictwo/zarząd/management/etc – a już pod żadnym pozorem nie może być związany finansowo z wypłatą programisty. Dlaczego? Przyciśnięty programista może bardzo łatwo wygenerować dowolne pokrycie kodu i to przy dosyć małej ilości pracy. Pisząc odpowiednią ilość testów jednostkowych bez asercji można uzyskać 100% pokryci...