Pokrycie kodu środka tylko nowym kodem

Question

Poszukujemy kreatywnego sposobu pomiaru zasięgu kodu na nowym kodzie, niezależnie od istniejącego kodu. Mamy duży, starszy projekt i chcemy zacząć uzyskiwać 90 +% pokrycia na każdą nową funkcjonalność. Chcielibyśmy w łatwy sposób przejrzeć raport, który odfiltrowuje starsze kody, aby upewnić się, że nowa funkcjonalność spełnia nasze zadanie. Oczywiście wciąż szukamy coraz większego ogólnego zasięgu projektu, ale potrzebujemy nie-ręcznego sposobu na przekazanie nam opinii na temat nowej aktywności kodu. Mamy to działa do analizy statycznej, ponieważ możemy spojrzeć na daty w plikach źródłowych. Ponieważ Cobertura analizuje pliki klas, mają nowe daty i ta technika nie działa.

Jakieś pomysły?

Stos:

Java 1.5 JUnit Cobertura Hudson

Answer 1

rzucić okiem na emma.sourceforge i Associated Eclipse plugin here (jeśli używasz Eclipse)

myślę, że to narzędzie może odpowiedzieć Twoje potrzeby, wybierając dokładnie to, co przetestować dla pokrycia.

Answer 2

Mamy podobną sytuację. Chciałem przetestować nowy kod, ale nie mogłem przetestować całego starego kodu naraz. To, co zrobiliśmy, nie jest dokładnie tym, o co prosiłeś, ale może dać ci pomysł.

Mamy plik o nazwie linecoverage.standard i plik o nazwie branchcoverage.standard, który jest dostępny na serwerze kompilacji (i kopiach lokalnych). Mają numer wewnętrzny z aktualnymi limitami zasięgu linii i gałęzi. Jeśli sprawdzony kod jest poniżej standardu, nie powiedzie się jego kompilacja. Jeśli jest w standardzie, przechodzi przez kompilację. Jeśli jest to POWYŻSZE kryterium, nowy standard jest zapisany jako równy bieżącemu zakresowi.

Oznacza to, że nasz zasięg kodu nigdy się nie pogorszy i powinien powoli rosnąć. Jeśli nowy kod wynosi 90%, zasięg będzie się zwiększał. Możesz także ustawić cel, na przykład podnieść standard o 1 co tydzień, aż osiągnie ostateczny cel (90%). Konieczność dodania kilku testów tygodniowo do starego kodu nie jest złym pomysłem, jeśli jest rozłożona na wystarczającą ilość czasu.

Nasz aktualny zasięg wynosi do 75% ish ... całkiem dobrze, biorąc pod uwagę stawkę 0% poniżej roku temu.

Answer 3

Zrobiłem to dla dużego projektu C++, używając svn blame w połączeniu z wyjściem gcov. Jeśli połączysz te dwa wyniki razem, otrzymasz informacje o wersji i informacje o zasięgu dla każdej linii. Właściwie to załadowałem to wszystko do bazy danych, aby wykonać zapytania (np. pokaż mi wszystkie nieprzykryte linie napisane przez joe od r1234). Jeśli potrzebujesz tylko zagregowanej liczby, możesz po prostu uniknąć liczenia "starych" niezabezpieczonych linii w swojej sumie.

Answer 4

IMO najlepszym rozwiązaniem jest podzielenie kodu na sekcje "nowe" i "starsze". Następnie uruchom analizę zasięgu testowego tylko w sekcji "nowy" lub zignoruj ​​wyniki dla sekcji "starej".

Dwa najlepsze sposoby osiągnięcia tego to: a) podzielenie bazy kodów na dwa drzewa źródłowe (dwa projekty z zależnością między nimi) lub b) utrzymywanie dwóch odrębnych hierarchii pakietów w jednym projekcie.

Prawdopodobnie dwa oddzielne projekty są lepsze, ale może nie być możliwe, jeśli istnieje cykliczna zależność między starszą bazą kodową a nową bazą kodów (stary kod zależy od nowego kodu, a nowy kod zależy od starego kodu). Jeśli potrafisz nim zarządzać, jednokierunkowa zależność między starym a nowym kodem sprawi, że połączony kod będzie łatwiejszy do zrozumienia.

Kiedy już to zrobisz, dostosuj coberturę tak, aby analizowała tylko wybrane bity lub przynajmniej skup się na "nowej" części bazy kodu. Dodatkową wskazówką jest to, że w tym schemacie najlepiej przenieść fragmenty kodu z sekcji "starszej" do sekcji "nowa" podczas refaktoryzacji/dodawania do nich testów (jeśli kod często porusza się w przeciwnym kierunku, to nie jest tak dobry :-).

Answer 5

Zrobiliśmy to jak poniżej, używając sonar.exclusions właściwość: Używamy Sonar do wyświetlania raportów pokrycia kodu (zgłaszane przez Cobertura).

a) Zidentyfikuj klasy, na których raport o pokryciu chcesz nie być uwzględniany (klasy Legacy) Użyj klienta SCM cmd. np: Pliki p4 // depot/... @ 2000/01/01, @ 2013/13/07 git log --until = "5 dni temu"

Bezpośrednie tej listy do pliku. Będziesz musiał wykonać pewne analizy w oparciu o używane narzędzie SCM, a plik docelowy powinien zawierać jedną nazwę pliku w linii.

eg. the destination file is excludeFile.list should look like below: 
abc.java 
xyz.java 
... 

b) Teraz ... kiedy integrujesz się z Sonarem (z Jenkins Job), użyj poniższej właściwości.

-Dsonar.exclusions=<filename> 

A twój ostateczny raport pokrycia w Sonar zawiera tylko nowych klas (dodane po 07/13 w powyższym przykładzie).