Please provide guidance on how to handle situations where the reduction in the total number of code steps causes an inability to meet jacoco coverage requirements.

[ricordanza]

In this PR, I moved a part of the code in AuthZpeClient.java to another library.
As a result, I am no longer able to meet the min code coverage requirement specified by jacoco.

[WARNING] Rule violated for bundle athenz-zpe-java-client: lines covered ratio is 0.8702, but expected minimum is 0.8711

I'm considering adjusting code.coverage.min to an appropriate value to address this issue, but I don't know how to calculate the suitable value.
Could you please explain the calculation method?

This PR is just an example, and I'm struggling with how to handle similar cases in the future.
If you have any other recommended approaches, could you please let me know?

[havetisyan]

The calculation method is based on what Jacoco reports. So if we removed code and that decreased the percentage, then it reports the value as 0.8702 so that's the value that needs to be used in the pom.xml

[havetisyan]

alternatively, I usually take this opportunity to add other test cases to increase the code coverage and not decrease it. So I'll take a look at jococo output and see what functions haven't been covered and add test cases for those (even if not part of my PR) and thus increase the code coverage more.

[ricordanza]

Thank you for your response.

then it reports the value as 0.8702 so that's the value that needs to be used in the pom.xml

We will proceed with the solution you suggested.

Regarding this issue, upon further investigation, we found that the ValidateRokeToken code in AuthZpeClient.java sometimes goes through certain steps and sometimes does not.

We suspect that this is due to conditional branching dependent on the cache state, and we believe that the cache cleanup may be affecting it, although we have not been able to pinpoint the exact cause.

// -Dyahoo.zpeclient.updater.monitor_timeout_secs=1
// -Dyahoo.zpeclient.updater.cleanup_tokens_secs=1

[havetisyan]

Let's keep this issue open. I actually fixed similar case with another module where we had cache timeouts/cleanup affecting test cases (in that case the test case would actually fail). The correct fix is to provide an interface/api to disable/stop that behavior after the test is complete so it doesn't affect other test cases.