Java Log Coverage tool

Question

Czy są jakieś narzędzia lub strategie generowania raportu "Log report" na (Java, log4j)? Podobnie jak zasięg kodu, ale zapewniający, że nie ma dużych metod, klas lub pakietów, które nie logują niczego.

Podczas kodowania usług internetowych zespół mnie nie zapisuje wielu instrukcji dziennika. Podczas debugowania problemu w czasie rzeczywistym z uruchomieniem, kodu produkcyjnego, zawsze żałujemy, że nie mieliśmy. Nieuchronnie próbujemy odtworzyć błąd w naszym środowisku testowym z dołączonym debuggerem lub dodatkowymi instrukcjami logów, które mogą być bardzo trudne w zależności od struktury i interakcji.

Czy ktoś używa tego jako metryki jakości kodu?

Answer 1

Pokrycie kodu wymaga specjalnego oprzyrządowania, ponieważ próbujesz sprawdzić, czy kod produkcyjny jest wykonywany przez dowolny test. To, o co prosisz, jest trochę bardziej niejasne i może być albo o wiele łatwiejsze ("czy rejestracja jest wykonana dla tej dużej klasy?"), Albo o wiele trudniejsze do punktu niemożliwego ("czy zapisaliśmy metodę, która złamie produkcję ? ").

Dla pierwszego pytania można dość szybko uruchomić skrypt powłoki, aby wykonać zadanie. Oto szkielet w Perlu, na przykład. Tutaj zakładam, że używamy SLF4J i że zobaczenie importu "LoggerFactory" jest wystarczającym dowodem na to, że jest rejestrator.

while ($filename = shift) { 
    open my $in, "<$filename"; 
    my $loc = 0; 
    my $log = "NO LOGGER"; 
    while (<$in>) { 
     $loc++; 
     if (m/import org.slf4j.LoggerFactory/) { 
      $log = "has logger"; 
     } 
    } 
    print "$filename : $loc LOC $log\n"; 
    $total{$log} += $loc; 
} 
print "\n\nTOTAL LOGGED: $total{'has logger'}\nTOTAL UNLOGGED: $total{'NO LOGGER'}\n"; 

i mogę uruchomić to z mojej skorupy przejechać wszystkich plików Java w małym projekcie z

$ find . -name \*.java -exec perl haslog.pm {} \+ 

Działa to tylko dla małych projektów, i to dość kruche, ale byłoby miło Trzeba dużo pracy, aby stworzyć mocniejszą wersję tego.

Answer 2

Wiele dzienników może być szumem iz mojego doświadczenia wynika, że ​​zawsze znajdowanie śledzenia za pomocą bolesnych dzienników. Powiedziawszy, że jeśli logi są dobrze zarządzane, możesz uzyskać dobrą diagnostykę/raportowanie. Jednym z powodów nieprawidłowego testowania kodu jest posiadanie dużej ilości dzienników w kodzie produkcyjnym. Deweloperzy zwykle robią to, dodając instrukcję dziennika, gdy rozwijają się, aby sprawdzić, czy kod działa, w związku z tym zachęca on do niepodpisywania testu z odpowiednim stwierdzeniem. To, czego potrzebujesz, to wiele małych klas, które są dobrze przetestowane razem. Twierdzenie powinno dokładnie wskazywać, dlaczego test się nie udaje.

Powiedzmy, że w swojej ścieżce kodu spodziewasz się, że coś się stanie, co jest jego główną odpowiedzialnością (np. Utworzono wpis DB, aby zarejestrować użytkownika/lub kogoś, kto się loguje), kiedy mówię, że to jego główna odpowiedzialność, nie mówię o stronie efekt, który dzieje się w ścieżce kodu. Jeśli w głównej ścieżce kodowej znajduje się warunek błędu, wyjątek powinien być wyrzucony do stosu, aby można było go zarejestrować i przekonwertować na komunikat przyjazny dla użytkownika. Wyrażenia RuntimeExceptions są tutaj dobre, ponieważ nie chcesz przechwytywać tych wyjątków, dopóki nie przejdą one aż do warstwy widoku. Efekty uboczne mogą być również rejestrowane, ponieważ są jak informacje/ostrzeżenia.