I’m questioning the appropriateness of including a default logging implementation for test scope, which was done in . The idea is that without it we would get SLF4J warnings to stdout if a tested class logged anything, saying that there was no SLF4J implementation present. The problem is that if there is, then the build gets riddled with extraneous log messages that probably aren’t relevant. (A test might be testing that a method produces an error, for example; in that case wouldn’t need that logged.)

Another issue is that, once it’s defined, it causes problems in subproject tests if the main project defines a different logging implementation; see . SLF4J-592 (recently closed in favor of SLF4J-450) might mitigate the dueling implementations problem, but we’ll still have the issue of seeing mostly useless output stuff during tests.

There may be other alternate or complementary ways to prevent the logs and the SLF4J warnings during tests.

• Clogr could release a NOP logging implementation that did nothing, and we could define that for tests. (Of course we would still have the dueling implementations problem in tests of applications.)

• Clogr could add a feature that would detect if no implementation were present, and default to a NOP operations. Or maybe Clogr could have an option whether it defaulted to NOP or whether it defaulted to logging for stdout, but for the latter it’s probably better to have some dependency to do that. Or maybe Clogr could not default to anything, but have an option to set the default behavior, and we could do that at the top of relevant tests. This would only take care of logging that goes through Clogr, but this may be our biggest source of problem at the moment—testing logging code that uses Clogr, not some SLF4J logging that happens several layers deep in some other library. This might give us the biggest bang for the buck, and be complementary to other approaches.