Since your comments where excellent pointers.
Let me share the following snippet:

…
private Appender mockAppender;

@Before
public void setupMocksAndTestee() {
mockAppender = Mockito.mock(AppenderSkeleton.class);
Logger logger = Logger.getLogger(testee.getClass());
logger.addAppender(mockAppender);
logger.setLevel(Level.INFO);
}

@Test
public void infoLogEventReceived() {
testee.doSomething();

ArgumentCaptor loggingEventCaptor = ArgumentCaptor.forClass(LoggingEvent.class);
verify(mockAppender).doAppend(loggingEventCaptor.capture());

LoggingEvent loggingEvent = loggingEventCaptor.getValue();
assertEquals(“Expected info log message.”, loggingEvent.getRenderedMessage());
assertEquals(Level.INFO, loggingEvent.getLevel());
}
…

Pre-Mockito, I avoided Mocks and built my own test doubles where I could. This way I didn’t have my tests tied to the api-calls of the mocked object, but just made assertions-about-state. This generally meant one up front cost to build the test double (i.e. this one, or an InMemoryRepository, etc.), and then very small incremental costs to use this new test collaborator.

I still do this in Post-Mockito codebases. Recently I was writing some classpath repository mocking code. It was verbose, and required repeating frequently as boilerplate everywhere I wanted to set up this mock test double. Even when refactored into a parametrized method call, I didn’t like it. Too hard to see the important interactions in my test. So I re-wrote a test double that I only could make state assertions on at the end. Much better, imho.

I wonder, why you just didn’t mock the logger. Afterwards you would check whether some collaborations appeared, Mockito.verify(mockLogger).info(Session Size for session id: + sessionId + (approx. total + (7 + 3 + 1 + 4 + 1) + bytes)). I do like this when I have to test some logging. Can you provide cons & prons in those two approaches?

cheers