Strumento copertura log Java

Question

Esistono strumenti o strategie per generare un report "Copertura log" su (Java, log4j)? Come la copertura del codice, ma assicurando che non ci siano metodi, classi o pacchetti di grandi dimensioni che non registrano nulla.

Durante la codifica dei servizi Web, il team di me non scrive molte dichiarazioni di registro. Quando eseguiamo il debug di un problema in tempo reale con l'esecuzione, il codice di produzione, vorremmo sempre averlo. Inevitabilmente, proviamo a riprodurre il bug nel nostro ambiente di test con un debugger allegato o aggiunte dichiarazioni di registro aggiuntive, che possono essere molto difficili a seconda delle strutture e dell'interoperazioni coinvolte.

Qualcuno usa questo come una metrica di qualità del codice?

Answer 1

La copertura del codice richiede una strumentazione speciale perché si sta cercando di scoprire se un codice di produzione viene esercitato da un test. Quello che stai chiedendo è un po 'più vago e potrebbe essere molto più semplice ("qualsiasi registrazione fatta per questa grande classe?") O molto più difficile fino al punto di impossibile ("abbiamo registrato il metodo che sta per interrompere la produzione? ? ").

Per la prima domanda, è possibile eseguire rapidamente uno script di shell per eseguire il lavoro. Ecco uno scheletro in Perl, per esempio. Qui, presumo che stiamo usando SLF4J e che vedere l'importazione di "LoggerFactory" è una prova sufficiente per supporre che ci sia un logger.

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"; 

e posso correre questo dal mio guscio di eseguire più di tutti i file Java in un piccolo progetto con

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

Questo funziona solo per le piccole dimensioni dei progetti, ed è abbastanza fragile ma wouldn essere un sacco di lavoro per fare una versione più robusta di questo.

Answer 2

Un sacco di log può essere rumore e nella mia esperienza ho sempre trovato doloroso tracciare i tronchi. Detto questo, se i registri sono gestiti bene, è possibile ottenere una buona diagnostica/reporting. Uno dei motivi per cui il codice non è stato testato correttamente è dovuto al fatto di avere molti registri nel codice di produzione. Quello che gli sviluppatori tendono a fare è aggiungere un'istruzione di registro quando si stanno sviluppando per verificare il funzionamento del codice, di conseguenza incoraggia a non scrivere un test con la giusta affermazione. Quello di cui hai bisogno sono tante piccole classi ben collaudate composte insieme. L'asserzione dovrebbe dirti esattamente perché il test sta fallendo.

Diciamo che nel tuo percorso di codice ti aspetti che succeda qualcosa che è la sua responsabilità principale (ad es. Crea una voce DB per registrare l'utente/o qualcuno che effettua il login), quando dico la sua responsabilità principale non sto parlando di un lato effetto che accade nel tuo percorso di codice. Se si ha una condizione di errore nel percorso del codice principale, l'eccezione dovrebbe essere lanciata fino in cima allo stack se fosse possibile registrarla e convertirla in un messaggio user-friendly. Le eccezioni Runtime sono buone qui perché non vuoi catturare queste eccezioni fino al livello di vista. Gli effetti collaterali possono essere registrati anche perché sono come informazioni/avvisi.