Hi everybody. I was wondering if somebody has found a solution for the problem that logging - in general, not just using Logback - lowers the coverage of application code because code after if(logger.isDebugEnabled()) is either executed or not, but not both, by the tests. It would be necessary to execute every test-method twice: once logging ALL and once logging OFF. Ignoring cases like that is not the solution because it can actually happen that a bug is enclosed or caused by such an if scope. It once happened that a variable was initialized inside of a larger if(logger.isDebugEnabled()) by mistake. This resulted in a behavior where everything worked until the logging level of that class was raised from DEBUG to INFO - which was a little bit nasty because everything would work again after lowering the level to DEBUG to look what's wrong... :p Does anyone have a good idea (or even a solution) how to tackle that problem? Regards, Joern.
To modify code coverage software to handle this situation? LZ Joern Huxhorn-2 wrote:
Hi everybody.
I was wondering if somebody has found a solution for the problem that logging - in general, not just using Logback - lowers the coverage of application code because code after
if(logger.isDebugEnabled())
is either executed or not, but not both, by the tests.
It would be necessary to execute every test-method twice: once logging ALL and once logging OFF.
Ignoring cases like that is not the solution because it can actually happen that a bug is enclosed or caused by such an if scope.
It once happened that a variable was initialized inside of a larger if(logger.isDebugEnabled()) by mistake. This resulted in a behavior where everything worked until the logging level of that class was raised from DEBUG to INFO - which was a little bit nasty because everything would work again after lowering the level to DEBUG to look what's wrong... :p
Does anyone have a good idea (or even a solution) how to tackle that problem?
Regards, Joern. _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
----- -- Lukas Zapletal http://lukas.zapletalovi.com -- View this message in context: http://www.nabble.com/Logging-and-test-coverage-tp21974373p22205571.html Sent from the Logback User mailing list archive at Nabble.com.
Thorbjørn Ravn Andersen wrote:
Joern Huxhorn skrev:
Does anyone have a good idea (or even a solution) how to tackle that problem? Use the log.whatever("foo {} bar {}", ...) approach and avoid the if?
Lukas Zapletal wrote:
To modify code coverage software to handle this situation?
LZ
Hi guys, neither suggestion would help in our situation. We have a large code-base which contains if(logger.isXxxEnabled()) logger.xxx(...); Changing all loggings statements isn't an option. Beside that, we also have code like if(logger.isXxxEnabled()) { // perform lots of preparation, construct large message using StringBuilder etc. logger.xxx(builder.toString()); } Code like that may actually contain a bug (and did so in the past) so I *want* to run all tests, once with Level.ALL and once with Level.OFF. I thought maybe someone has already found a solution but I should probably ask that question on a junit mailinglist... Thanks anyway, Joern.
Probably pointing out the obvious, but running all the tests twice, with logging turned off on one run and logging at trace level on the other, seems like would be a solution. It shouldn't be too hard to configure a couple of JUnit suites which set up logback in two different ways prior to running. Doubles the test run time, of course, but you could configure it so that that only occurs on the continuous integration server rather than for developer runs.
participants (4)
-
Joern Huxhorn -
Lukas Zapletal -
Robert Elliot -
Thorbjørn Ravn Andersen