Examples of unit testing components that use Strict/LazyLogging

[Johnlon]

I have components where I want to unit test their logging side effects.

It would be good if the documentation demonstrated the recommended patterns for testing the logging of code that uses Strict/LazyLogging - apologies if I have missed this.

For now .. It would seem that the two traits require me to leave my classes non-final and override the method defined in the trait - is this the recommendation? Can you confirm if there is a more elegant approach and/or one where I can retain final classes.

[Johnlon]

PS It would seem that this addition to the fold (the name is a work in progress)...

trait LazyLoggingAlt extends Logging {

  protected def loggerFactory: ILoggerFactory

  override protected lazy val logger: Logger = Logger(loggerFactory getLogger getClass.getName)
}

... would allow me a degree of standardisation/code structure whilst leaving open the option of how I obtain my logging - eg I might constructor inject the ILoggingFactory.

[andrewmeyerBR]

I agree and would like to elevate this issue. We are using ScalaTest and a custom in-memory log appender to build acceptance tests that validate logging behavior. Unfortunately, these tests cannot be run in parallel at the moment because each test suite needs its own isolated logging context.

[Johnlon]

Some time later ....
I think in the end the only pattern that really works well is DI of the ILoggerFactory.
Allows tests to run concurrently and leaves the logging impl entirely open.
Put together a lib to facilitate testing stuff that uses Slf4J https://github.com/portingle/slf4jtesting

[andrewmeyerBR]

Agreed. This was a similar approach we took too. I wrote two logger factory wrappers: one which is used in production code and returns a logger named after the current containing class, and the other which is static and used in test suites and always returns the same logger (named after the test suite). The logger factory wrapper is DI'd throughout the application, so it can be swapped out at the top-level based on production or testing scenarios.

[Johnlon]

Works really well.

[Ophirr33]

If you rely on Logger.takingImplicit[SomeCanLog], you can't rely on just using an slf4j logger factory/logger since you need to rely on a LoggerTakingImplicit. Problem is, that class is final, so it's hard to even mock.

[karolchmist]

Another way is to mock the underlying SLF4J logger:

    val mockedLogger: org.slf4j.Logger = mock[org.slf4j.Logger]

    val testedClass = new SomeClassWithLazyLogger() {
        override lazy val logger = com.typesafe.scalalogging.Logger(mockedLogger)
      }