The most popular post in this somewhat dormant blog is Testing logging behaviour in four code lines flat. The approach described there relies on everyones favourite unit testing mocking swiss army knife – Mockito. To achieve the purpose of unit testing logging Mockito is however not a required drink, some simple Log4j coding goes a long way:
import org.apache.log4j.SimpleLayout;
import org.apache.log4j.WriterAppender;
import static org.hamcrest.CoreMatchers.is;
import org.junit.Test;
import static org.junit.Assert.assertThat;
public class FooTest {
@Test
public void testMethod() {
StringWriter stringWriter = new StringWriter();
Logger.getRootLogger().addAppender(new WriterAppender(new SimpleLayout(), stringWriter));
doStuffThatCausesLogging();
assertThat(stringWriter.toString(), is("WARN - doh\n"));
}
}
The code is still acceptable and quite compact. However the expressive niceties Mockito provides are lost and making assertions about logging levels, timestamps and multiple logging invocations takes a lof of cruft. Hence I really see few reasons for this approach if Mockito is available.
Slackhacker 
Pingback: Testing logging behaviour in four code lines flat « Slackhacker
Some things should not be tested and one of those things is logging.
Too much testing can slow you down on the short term, because you need to spend more resourced on writing tests instead of realizing value that is important to the business.
But it can also be damaging on the long term, because refactoring lead to a lot of changes in the tests, making them a drain on your resources instead of an asset.
My personal believe is that mocking frameworks are being overused in a lot of company. Focus more on writing integration tests to see that the system really works instead of a lot of lower level unit tests (relying on mocking).
I think the main problem in the context of this post is that many applications log to much (and on a far too high severity level). Logging on WARNING level (and above) should only be applied to actionable events that are likely to warrant immediate attention, e.g uncaught runtime exceptions (i.e. probable software defects), possible malicious user activity, integration point down time etc. Failure to log such events constitutes a significant risk to a production system and could render attempts to reproduce bug reports impossible. Hence – log less but when you do log, make sure (test!) that it’s really done!
Even for the log levels warn and higher, I would ask myself the question at least 2 times if some form of testing is really needed to verify that the exception is logged.
Pingback: Test log4j logging – add appender to root | Dawei's space