Java-Log-Coverage-Tool

Question

Gibt es Tools oder Strategien zum Generieren eines Berichts "Log-Coverage" auf (Java, log4j)? Wie Code Coverage, aber stellen Sie sicher, dass es keine großen Methoden, Klassen oder Pakete gibt, die nichts protokollieren.

Bei der Codierung von Webdiensten schreibt mir das Team nicht viele Protokollanweisungen. Beim Debuggen eines Echtzeitproblems mit laufendem Produktionscode hätten wir uns immer gewünscht. Wir versuchen unweigerlich, den Fehler in unserer Testumgebung entweder mit einem angehängten Debugger oder zusätzlichen Protokollanweisungen zu reproduzieren, was je nach den beteiligten Strukturen und Interaktionen sehr schwierig sein kann.

Verwendet dies jemand als Codequalitätsmetrik?

Answer 1

Die Codeabdeckung erfordert eine spezielle Instrumentierung, da Sie herausfinden möchten, ob ein Testcode einen Produktionscode ausgibt. Was Sie fragen, ist ein wenig vager und könnte entweder viel einfacher sein ("ist jede Protokollierung für diese große Klasse gemacht?") Oder viel schwieriger bis zur Unmöglichkeit ("haben wir die Methode protokolliert, die in der Produktion brechen wird? ? ").

Für die erste Frage könnten Sie ziemlich schnell ein Shell-Skript erstellen, um die Aufgabe zu erledigen. Hier ist zum Beispiel ein Skelett in Perl. Hier nehme ich an, dass wir SLF4J verwenden und dass der Import von "LoggerFactory" ausreichend ist, um davon auszugehen, dass es einen Logger gibt.

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

und ich kann aus meiner Schale laufen über alle Java-Dateien in einem kleinen Projekt laufen mit

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

Dies funktioniert nur für kleine Projekte, und es ist ziemlich spröde, aber es wouldn Es ist eine Menge Arbeit, um eine robustere Version davon zu machen.

Answer 2

Viele Protokolle können Lärm sein und meiner Erfahrung nach fand ich die Verfolgung durch Protokolle immer schmerzhaft. Wenn die Protokolle jedoch gut verwaltet werden, können Sie eine gute Diagnose/Berichterstellung erhalten. Einer der Gründe dafür, dass der Code nicht richtig getestet wird, ist, dass der Produktionscode viele Protokolle enthält. Was Entwickler normalerweise tun, ist das Hinzufügen einer Log-Anweisung, wenn sie entwickelt werden, um zu überprüfen, ob der Code funktioniert. Daher wird empfohlen, keinen Test mit der richtigen Assertion zu schreiben. Was Sie brauchen, sind viele kleine Klassen, die gut zusammen komponiert sind. Die Behauptung sollte Ihnen genau sagen, warum der Test fehlschlägt.

Nehmen wir an, in Ihrem Code-Pfad erwarten Sie etwas, was seine Hauptverantwortlichkeit ist (zB Erstellt einen DB-Eintrag, um Benutzer/Benutzer einzuloggen), wenn ich seine Hauptverantwortung sage, spreche ich nicht von einer Seite Effekt, der in Ihrem Code-Pfad passiert. Wenn Sie eine Fehlerbedingung im Haupt-Code-Pfad haben, sollte die Ausnahme den ganzen Stapel nach oben geworfen werden, wo Sie diese protokollieren und in eine benutzerfreundliche Nachricht konvertieren können. RuntimeExceptions sind hier eine gute Sache, weil Sie diese Ausnahmen nicht bis zum View-Layer erfassen möchten. Nebenwirkungen können auch protokolliert werden, da sie wie Informationen/Warnungen sind.