`val logger = KotlinLogging.logger {}` reports no code coverage

[snowe2010]

due to the function invocation, using the shorthand of the logger instantiation causes this line to reported as not covered by tests.

[oshai]

I don't know what coverage tool you're using, but when I tested it in IntelliJ coverage it report as the line was visited (see the green mark on the side bar):

[snowe2010]

JaCoCo reports the line as visited, but missing a branch. IntelliJ doesn't report properly at all. It misses half the stuff that jacoco covers.

[oshai]

We can add method invocation which might solve the issue, but I'm hesitant to do that just for coverage since it is a waste of cpu cycles. Is adding it as a configuration a good alternative?
Another option is to use the inheritance flavour.
What do you think?

[snowe2010]

I'm not sure what you mean by

adding it as a configuration

And for the inheritance option, do you mean inherit a logging class?

[oshai]

adding it as a configuration will be something like starting your coverage run with a system property like -Dkotlin.logging.coverage

For inheritance I mean inherit KLogging as you can see in the example here: https://github.com/MicroUtils/kotlin-logging/wiki#usage

[oshai]

@snowe2010 will you be able to test such flag or should I close the issue?

[snowe2010]

Sorry, I've been out of the country for a while. I will try to get back to this tonight!

[snowe2010]

So the companion object version works just fine. Thank you very much. How does that actually work though? What is placing a logger object into my object from the Companion? And I am still not sure I understand what you mean by

adding it as a configuration will be something like starting your coverage run with a system property like -Dkotlin.logging.coverage

[oshai]

OK, so can we close the issue? The thing is that coverage is checking your code and not companion code. About the flag it is not that important if it's working for you.

[snowe2010]

Yes, thanks for the help!

[sluongng]

I would like to ask to reopen this issue.

Currently the recommended logger setup is not checked by jacoco code coverage. This may affect teams' adoption of this library since it affect their code coverage metric.

Its better to have a discussion on how to solve this issue moving forward

[sluongng]

the above are the 2 screenshots of current jacoco coverage which showed missed instruction

Kotlin-logging 1.6.26
Jacoco 0.8.4
Surefire 3.0.0-M3

[oshai]

@sluongng thanks for raising the issue again. My suggested solution is to have a JVM arg like -Dkotlin.logging.coverageAggresive and then activate it on the coverage run. What do you think about that? would you like to test that? or do you have other idea?

[sluongng]

@sluongng thanks for raising the issue again. My suggested solution is to have a JVM arg like -Dkotlin.logging.coverageAggresive and then activate it on the coverage run. What do you think about that? would you like to test that? or do you have other idea?

The downside of adding JVM arg is that its a bit hard to check-in this arg into git unless you embeding it into a dockerfile or abstracting your project behind a Makefile layer so I dont find it to be an ideal solution.

I am relative new to kotlin but I think for start, we can just document a pattern to exclude these logging methods in the Jacoco report generator. This pattern then will be check-in into git via maven pom file or gradle build file.