How to Write Unit Tests for Logging

There are two types of logging:<p>a) Logs which break the program semantics when missing. That means, the program does not work &quot;as expected&quot; anymore for any directly or indirectly impacted enduser.<p>b) Logs that have no semantic impact when missing. No one will notice that they are missing, unless there is any other problem. These logs are solely meant to better understand the program operations.<p>Logs of type A should be tested like everything else. But logs of type B - I don&#x27;t think I would test them.<p>While it is not nice to have a failure in production and figuring out only at that time that the logging doesn&#x27;t work, I think that is even worse to break tests because of logging changes. Logging usually is so easy that it is an all- or nothing thing. I&#x27;m not saying that it does not have advantages to test for these kind of logs, but from my experience it is not worth the costs in 99% of the cases.

It seems that the boundaries of what a unit test should cover have never been clearly defined. In my opinion, unit testing should only cover logic that does not have side effects (like writing to disk or communicating over a network). If you want to test external side effects, you should write functional or integration tests for them.

I usually don&#x27;t test the logging. However, sometimes I get tests for the logging messages &quot;for free&quot;. That happens when I break out some logic in its own function, and I want logging on what happened in that function (definitely not all the time, but is sometimes useful). Then the function can return its result, and a list of logging messages to output. When asserting the result, I can also assert on the logging messages.<p>It&#x27;s what I describe in &quot;Returning a message list&quot; in this post: <a href="https:&#x2F;&#x2F;henrikwarne.com&#x2F;2020&#x2F;07&#x2F;23&#x2F;good-logging&#x2F;" rel="nofollow">https:&#x2F;&#x2F;henrikwarne.com&#x2F;2020&#x2F;07&#x2F;23&#x2F;good-logging&#x2F;</a>

In Go, I test my log output easily: my logger instance’s output is set to a buffer, call the function under test, assert log contents. If another system depends on it, it gets tested. Our acceptance level tests operate largely on logs.

You can use log and monitoring signals to whitebox test certain implementation details to an otherwise stateless interface.<p>I would say it&#x27;s not great practice, but, it can remove a lot of contortions to be able to make assertions about the execution path taken when doing a unit test.<p>If I have a tricky thing to test. I ask, if I added the required operational monitoring (e.g. queue sizes)? Would I suddenly be able to test this easier? Would it make the test more self explanatory. If the answer is yes I might add the monitoring and then do the unit testing. If the answer is no I have to refactor the implementation for testability.<p>conclusion: exposing logs and especially monitoring counters to unit tests can actually super charge your testing and leave you net positive

I’ve written a sink for the Serilog structured logging library specifically with this in mind: testing logging from code.<p>When doing TDD there is no reason to skip over logging (although that does seem to happen, everyone likes print debugging ;-) it’s just that sometimes it’s a bit clunky to which is why I wrote this tool. It supplies a secondary package that has FluentAssertions extensions to make testing even easier.<p>Code&#x2F;packages can be found here: <a href="https:&#x2F;&#x2F;github.com&#x2F;sandermvanvliet&#x2F;SerilogSinksInMemory" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;sandermvanvliet&#x2F;SerilogSinksInMemory</a><p>Edit: formatting

Log4J2 has a testing library that is pretty dope, you can use it to assert on log events and parameters passed and tweak your appenders so that you&#x27;re not spamming the console while the test runs.<p>Here&#x27;s the coordinates in gradle:<p>compile group: &#x27;org.apache.logging.log4j&#x27;, name: &#x27;log4j-core&#x27;, classifier: &#x27;tests&#x27;

Let&#x27;s write unit tests for unit tests!