Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expected coverage with variable threshold #545

Closed
realdadfish opened this issue Feb 16, 2024 · 2 comments
Closed

Expected coverage with variable threshold #545

realdadfish opened this issue Feb 16, 2024 · 2 comments
Assignees
Labels
Feature Feature request issue type S: postponed Status: work on the issue is not in the short term plans

Comments

@realdadfish
Copy link

realdadfish commented Feb 16, 2024

What is your use-case and why do you need this feature?

Configuring the boundaries of coverage checks, i.e. minBound and maxBound, is quite cumbersome, as they're "moving targets" as the project continues to be developed. Also, the corridor in which boundary checks are useful to be applied changes over time. A module with 1000 lines of code should of course have different boundaries than a module with 10.000 lines of code.

Describe the solution you'd like

Ideally, instead / in addition to the regular way of defining boundaries I'd like to be able to configure boundaries based on the number of lines of code in a module (Java and Kotlin), something like this:

verify {
    rule {
        bound(KoverThresholdBound(50) { loc: Int ->
             when {
                 loc < 1000 -> 10
                 loc < 5000 -> 5
                 loc < 10000 -> 2
                 default -> 1
        })
    }
}

So, following this example, the actual minBound and maxBound would be calculated like this:

val minBound = (expected - threshold).coerceAtLeast(0)
val maxBound = (expected + threshold).coerceAtMost(100)

The callback could also be shared by some custom build-convention plugin, so that one would only need to configure the expected coverage (50 in this case) per module.

@realdadfish realdadfish added Feature Feature request issue type S: untriaged Status: issue reported but unprocessed labels Feb 16, 2024
@shanshin shanshin added S: postponed Status: work on the issue is not in the short term plans and removed S: untriaged Status: issue reported but unprocessed labels Feb 16, 2024
@shanshin
Copy link
Collaborator

shanshin commented Feb 16, 2024

This solution is suitable only for a specific case.
For custom verification logic, logging, etc., I think it's better to add the execution of an action that would take the original coverage values:

E.g.

kover {
    ...
 
    coverage(MetricType.LINE, GroupingEntityType.APPLICATION) { coverage -> 
        // this action will be executed only when the coverage is evaluated
        if (coverage.totalCount > 0) {
            val coverageRate = coverage.coveredCount / coverage.totalCount
            if (coverageRate < 0.5) {
              throw Exception(" coverage for ${coverage.entityName} is below 50%: $coverageRate")
              // or log
            }
        }  
    }
   ...

}

@shanshin
Copy link
Collaborator

Closed in favor of #605

@shanshin shanshin closed this as not planned Won't fix, can't repro, duplicate, stale May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Feature request issue type S: postponed Status: work on the issue is not in the short term plans
Projects
None yet
Development

No branches or pull requests

2 participants