2011-01-10 10 views
20

Ich benutze slf4j und ich möchte meinen Code Unit-Test, um sicherzustellen, dass Warn/Fehlerprotokollmeldungen unter bestimmten Bedingungen generiert werden. Ich würde es lieber als strenge Komponententests betrachten, daher würde ich es vorziehen, die Protokollierungskonfiguration nicht aus einer Datei abrufen zu müssen, um zu testen, ob die Protokollnachrichten generiert werden. Der spöttische Rahmen, den ich benutze, ist Mockito.Was ist der beste Weg, um SLF4J-Log-Nachrichten im Unit-Test zu testen?

+0

Da SLF4J nur eine "Fassade" für andere Logging-Implementierungen ist, können Sie es nicht allein testen, sondern Sie müssen auch die Implementierung angeben, die Sie verwenden. – darioo

+1

@darioo - Nicht wahr. Ich könnte meiner Klasse einen Setter hinzufügen, um den Logger aus dem Test zu übergeben, dann eine verspottete Logger-Instanz weiterleiten und überprüfen, ob die entsprechenden Logaufrufe getätigt wurden. Ich hatte nur gehofft, eine elegantere Lösung zu bekommen, als eine Set-Methode hinzuzufügen, nur um zu testen und meine Logger-Instanz nicht final zu machen. –

+0

Nebenbei, das allgemein ausgezeichnete "Growing Object Oriented Software" Buch hat ein Kapitel über Unit Testing von Logging. Es ist nicht ganz überzeugend, aber es ist sicherlich gut durchdacht und lohnenswert (http://www.amazon.de/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627/ref=sr_1_1) ? ie = UTF8 & s = books & qid = 1294688741 & sr = 8-1) – skaffman

Antwort

9

Ich denke, Sie könnten Ihr Problem mit einem benutzerdefinierten Appender lösen. Erstellen Sie einen Testappender, der die org.apache.log4j.Appender implementiert, und setzen Sie Ihren Appender auf log4j.properties und laden Sie ihn, wenn Sie Testfälle ausführen.

Wenn Sie zurück zum Test-Harnisch rufen aus diesem appender können Sie die protokollierten Nachrichten überprüfen

+3

Es wäre sehr hilfreich, wenn Sie einige Codebeispiele anbieten könnten. – kenshinji

+0

@kenshinji Ein Beispiel ist hier gegeben: https://Stackoverflow.com/a/1828268/2521769 –

1

Anstatt SLF4J zu verspotten, können Sie die wichtigen Protokollierungsaufrufe setzen, um innerhalb ihrer eigenen Methoden zu testen, die Sie leichter spotten können.

Wenn Sie SLF4J wirklich zum Nachdenken anregen möchten, würde ich wetten, dass Sie Ihren eigenen Provider dafür erstellen könnten, der es Ihnen ermöglicht, einen Mock-Logger von der SLF4J-Seite zu liefern, anstatt einen in Ihre Serviceobjekte zu injizieren.

0

Ähnlich @Zsolt, können Sie log4j Appender und stellte sie auf den Logger, dann überprüfen Anrufe Appender.doAppend() verspotten. Dadurch können Sie testen, ohne den echten Code ändern zu müssen.

10

Zum Testen von slf4j ohne eine bestimmte Implementierung (z. B. log4j) zu verwenden, können Sie Ihre eigene slf4j-Protokollimplementierung bereitstellen, wie in this SLF4J FAQ beschrieben. Ihre Implementierung kann die protokollierten Nachrichten aufzeichnen und anschließend von Ihren Komponententests zur Überprüfung abgefragt werden.

Das Paket slf4j-test macht genau dies. Es handelt sich um eine speicherinterne slf4j-Protokollimplementierung, die Methoden zum Abrufen protokollierter Nachrichten bereitstellt.

5

Eine bessere Testimplementierung von SLF4J, die wirklich gut in einer Umgebung mit gleichzeitiger Testausführung funktioniert, ist https://github.com/portingle/slf4jtesting

Ich habe auf ein paar Diskussion über slf4j Protokolltests und die Grenzen des bestehenden Tests zustimmend nähert, wenn es darum geht, zur gleichzeitigen Testausführung.

Ich entschied mich, meine Wörter in Code zu setzen, und das Git Repo ist das Ergebnis.

+0

Hoffentlich bald eine dritte Antwort von jemandem, der eine noch bessere Test-Implementierung von SLF4j hat ....;) – Adam

Verwandte Themen