Ciągła integracja: upewnij się, że nowe zatwierdzenia są objęte testami.

Pracuję nad projektem, który ma dużo starego kodu, który nie jest objęty testami.Ciągła integracja: upewnij się, że nowe zatwierdzenia są objęte testami.

Czy istnieje sposób, w jaki mogę skonfigurować serwer integracyjny, aby sprawdzić, czy wszystkie nowe zatwierdzenia mają minimalną liczbę testów (np. Pokrycie wynosi> 70%)?

Zasadniczo, widzę dwie opcje:

jakoś skonfigurować serwer CI niepowodzenie kompilacji, gdy popełnione zmiany nie są pokryte testów jednostkowych. Zapewni to, że każdy fragment nowego kodu będzie miał testy, a testy starszych kodów będą wzrastać wraz z każdą zmianą.
Ustawienie progu zasięgu dla całego projektu i niepowodzenie kompilacji, jeśli procent pokrycia zmniejszy się po zatwierdzeniu. Problem polega na tym, że jeśli usunę klasę zawierającą 100 instrukcji i dodaję nową klasę z 50 instrukcjami, procent pokrycia wzrośnie bez pisania jakichkolwiek testów.

Jeszcze bardziej podoba mi się opcja 1, ponieważ wymusza zmiany w dotychczasowym kodzie w celu przetestowania jednostki. Powinno to zwiększyć ogólny zasięg testu.

W tej chwili używamy Jenkinsa jako naszego serwera CI i JaCoCo do pokrycia testowego. Maven służy do budowania projektu, a SVN jest naszą główną kontrolą źródła.

Źródło

2013-04-03 Denis Rosca

Należy pamiętać, że 100% pokrycia niekoniecznie jest możliwe, a nawet pożądane. Można również manipulować numerami zasięgu; napisanie testu jednostkowego dla klasy testowej może sztucznie zawyżyć zakres testowy. –

@MikeRylander Wiem, że nawet nie marzę o 100% zasięgu tego projektu. Ale wciąż uważam, że wymuszanie nowych zmian, aby przynajmniej część z nich była dobra. –

Obecnie pracuję nad rozwiązaniem tego problemu, który w dużym stopniu odnosi się do komentarza @MikeRylanders. http://pitest.org jest teraz zintegrowany z kontrolą wersji. Następne wydanie pozwoli na analizę plików według statusu scm. Następująca wersja umożliwi analizę według zakresu dat lub zatwierdzenia, co umożliwi serwerowi kompilacji sprawdzenie, czy zmodyfikowany kod spełnia określony wynik mutacji. – henry

Wiem, że można skonfigurować Jenkinsa do sprawdzenia, czy istnieje co najmniej jeden plik testowy jako część zatwierdzenia. To nie zapewni dobrego pokrycia testowego, ale przynajmniej wiesz, że były jakieś zmiany związane z testami.

Źródło

2013-04-03 18:47:36

Nie podoba mi się ten pomysł. Jeśli popełnisz coś, co sprawi, że poprzednio nie udało się przejść testowo, nie musisz również zatwierdzać pliku testowego. – JohnnyO

@JohnnyO Teoretycznie wadliwa kompilacja ** nie powinna ** być popełniana w pierwszej kolejności. Jeśli twoje testy jednostkowe nie są niestabilne lub nie są powiązane z zewnętrznymi zależnościami, co stanowi inny zestaw problemów, nigdy nie powinieneś popełniać zobowiązania do naprawienia uszkodzonych testów jednostkowych. –

Teoretycznie, oczywiście. W praktyce nie tak bardzo. Wyobraź sobie, że masz złe zatwierdzenie (powiedzmy, że zapomniałeś dołączyć jeden plik). Test przeszedł więc lokalnie, ale zakończył się niepowodzeniem w Jenkins. Jak w takim razie mógłbyś przekazać brakujący plik? – JohnnyO

Dla opcji 2 można użyć Jenkins JaCoCo plugin, aby śledzić zasięg kodu dla każdej kompilacji i ustawić wynik kompilacji, który ma zostać zaliczony lub nieudany, w zależności od danych pokrycia.

Ja też lubię opcję 1, ale nie znam wbudowanego sposobu, aby Jenkins mógł to zrobić. To powinno być dość łatwe (przynajmniej na poziomie klasy) do postprocesowego dane zasięgu i połączyć ją z informacją wersji SVN, coś jak:

Przetwarza pliki wyjściowe JaCoCo i znaleźć zajęcia, które mają 0% pokrycie
Pobierz plik (i), który zmieniono dla tej kompilacji na podstawie szczegółów wersji SVN (Jenkins udostępnia numery wersji dostępne w zmiennych środowiskowych, SVN_REVISION, jeśli jest tylko jedna dla tej wersji lub SVN_REVISION_1, SVN_REVISION_2, ... dla wielu)
Wydrukuj komunikat o błędzie, jeśli jakakolwiek zmieniona klasa ma zasięg 0%
Użyj Jenkins Text Finder plugin, aby nie powieść kompilacji, jeśli komunikat o błędzie zostanie wydrukowany.

To nie jest pełne rozwiązanie, jest trudniejsze w przypadku nowych metod lub linii, które nie są objęte testami. Daje mi pomysł na nową wtyczkę Jenkins ;-)

Źródło

2013-04-03 18:48:09

ale jak mogę skonfigurować tę wtyczkę, aby się nie powiodła, jeśli zatwierdzone zmiany nie są objęte testami? Jeśli dodaję jedną niewielką zmianę w starszym pliku, może to nie zmienić ogólnej metryki pokrycia, a tym samym nie zawiedzie kompilacji? –

Właśnie dlatego dodałem komentarze na temat pierwszej opcji. –

Niecierpliwie czekam na wtyczkę. –

Niektóre narzędzia do obsługi pokrycia (np. Cobertura) z wyłączeniem pakietów. W ten sposób możesz wykluczyć cały stary kod (zakładając, że może on być dopasowany do wzorca) i mieć coberturę tylko nowy kod (który obejmuje nowe zatwierdzenia).

Mam nadzieję, że to pomoże.

Źródło

2013-04-03 18:50:46

dziękuję za wkład, ale moim celem było sprawdzenie, czy testowany jest nowy kod, a także wymuszenie testowania zmian w starszym kodzie. –

zbudowałem narzędzie, które robi dokładnie to

https://github.com/exussum12/coverageChecker

przekazać w diff oddziału i wyjścia testowego pokrywę z testów. Narzędzie sprawdza, które linie w pliku różnicowym znajdują się również w pliku koniczyny. a nie kompilacji, jeśli mniej niż określony procent

używać

bin/diffFilter --phpunit diff.txt clover.xml 70

aby nie buduje, gdy mniej niż 70% diff jest objęte testem

mogę dodać inne formaty w razie potrzeby

Edit

dodałem jacoco

Bin/diffFilter --jacoco diff.txt jacoco.xml

Źródło

2017-08-17 16:46:27 exussum

Ciągła integracja: upewnij się, że nowe zatwierdzenia są objęte testami.

Odpowiedz

Powiązane problemy