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

Coverage minima: add more fine-grained control #55

Merged
merged 4 commits into from
Jan 1, 2024

Conversation

kitbellew
Copy link
Contributor

Along with existing statement minimum, add branch minimum. Also, include
this pair of control at the package and file level.

@kitbellew
Copy link
Contributor Author

@gslowikowski friendly reminder to review.

@kitbellew
Copy link
Contributor Author

@gslowikowski are you interested in pursuing this still?

@gslowikowski
Copy link
Member

Yes, I am. I didn't have enough time, when you created your pulls.

I've created some simple test projects to compare SCoverage with Cobertura and Jacoco for similar syntax constructs and it looks very different. I wasn't sure if SCoverage properly reports overall coverage.

Now I will try to find time and return to this problem. I will publish my test projects, and we will see if something in current code base should be changed before merging your pulls, or not.

@kitbellew
Copy link
Contributor Author

@ckipp01 rebased

@jozic
Copy link
Collaborator

jozic commented Dec 23, 2023

Hey @kitbellew
would you be interested in rebasing this?

@kitbellew
Copy link
Contributor Author

Hey @kitbellew would you be interested in rebasing this?

and them what will happen?

@jozic
Copy link
Collaborator

jozic commented Dec 23, 2023

I can review and if all is good merge and release it.
I know this PR is super old, but I've only recently got the member/release permissions from @ckipp01.
@gslowikowski seems inactive, at least in this repo, and I'm willing to give back to the community by keeping this plugin maintained. At least for now. So I'm offering some help with moving this forward.
If you don't need/want this anymore, I can totally understand it.

@kitbellew
Copy link
Contributor Author

@jozic ah, no problem, will do. (did it once before, and nothing happened subsequently, hence my question.)

@kitbellew
Copy link
Contributor Author

@jozic сделано.

@jozic
Copy link
Collaborator

jozic commented Dec 26, 2023

thanks @kitbellew
checking it now
would you mind adding an integration test to it folder following the pattern there?

@kitbellew
Copy link
Contributor Author

would you mind adding an integration test to it folder following the pattern there?

done.

@kitbellew
Copy link
Contributor Author

@jozic it might be easier to review one commit at a time, they are structured logically.

Copy link
Collaborator

@jozic jozic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks very nice, left some questions/suggestions

@@ -547,6 +551,32 @@ else if ( !module.getPackaging().equals( "pom" ) )
getLog().info( "Coverage aggregated reports completed." );
}

private MavenProject findAncestorModuleWithShortestBasedir()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like this is not really related to minimums we can set, right?
seems like it's similar to #104
could you please clarify why we need this here? Can we extract that to a separate PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, correct. the code is what we used in our production for many years, and it's likely that there were two unrelated changes to make everything work. will remove from this pr (and the linked one might be a better implementation).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a heads-up, i've merged #104, so dropping this particular change should be safe now.

{
if ( !checkCoverage( getLog(), "Package:" + pkgCoverage.name(), pkgCoverage,
minimumCoverageStmtPerPackage, minimumCoverageBranchPerPackage, false ) )
ok = false;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like this will continue even after after first false
should we instead use something like
CollectionConverters.asJava( coverage.packages() ).stream().allMatch?
or do you want it to run for each package no matter what?
same question for files

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good question. we can either report until first failure (in which case the user would fix something and then find out there's more), or report everything. options:

  • report everything
  • report only first failure
  • put the choice under yet another parameter.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally generate a report on a failure, to see what's not covered. So the first failure seems fine to me.
But I can also see a point of having all the packages/files checked at once.

How about we do fail-fast in this PR and then we can do a separate PR to add an extra flag, like failFast with true by default?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jozic good morning and happy new year.

i finally got around to working on this, and here's what i realized: we will have reporting on all packages and files if it's successful but will stop at the first error if it happens (with a single [ERROR] message after possibly a bunch of [INFO]/[DEBUG]). which is a bit weird since the opposite is probably of more interest.

so, i see several alternatives:

  • report everything, just like now
  • report everything, except use [DEBUG] for second and subsequent errors
  • collect all info/debug messages until the first error; if there are no errors, only then log the info/debug.

thoughts?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @kitbellew, happy New Year to you as well!

Good point, i guess reporting packages and files as debug for success and error for failure is a fair game. So we should probably leave it as you have it )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jozic all done and pushed.

private static boolean checkCoverage( Log logger, String metric, CoverageMetrics metrics,
double minimumStmt, double minimimBranch, boolean logSuccessInfo )
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo minimumBranch

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do

if ( is100( minimum ) && is100( actual ) )
{
logSuccess( logger, String.format( "Coverage is 100%: %s!", metric ), logSuccessInfo );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
logSuccess( logger, String.format( "Coverage is 100%: %s!", metric ), logSuccessInfo );
logSuccess( logger, String.format( "Coverage is 100%%: %s!", metric ), logSuccessInfo );

otherwise it fails with java.util.UnknownFormatConversionException: Conversion = ':'

would be nice to add module3 to your awesome tests checking this branch )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do


boolean ok = checkCoverage( getLog(), "Total", coverage,
minimumCoverage, minimumCoverageBranchTotal, true );
for ( MeasuredPackage pkgCoverage : CollectionConverters.asJava( coverage.packages() ) )
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this could be a large list, right? for files it will be even larger
how about wrapping this into if(minimumCoverageStmtPerFile > 0.0 && minimumCoverageBranchPerPackage > 0.0) to avoid checking every package/file with default/0 minimum?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do

@@ -0,0 +1,38 @@
def checkModule(logText, module, coverageLog) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome tests! Thank you.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you added the tests, i just duplicated :)

@kitbellew
Copy link
Contributor Author

perhaps windows tests will now succeed. added .replaceAll("\r\n", "\n").

Copy link
Collaborator

@jozic jozic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost there, let's make the test maven 3.9 compatible and we should be good to merge and then hopefully release soon after


boolean ok = checkCoverage( getLog(), "Total", coverage,
minimumCoverage, minimumCoverageBranchTotal, true );
ok = checkCoverage( getLog(), "Package:", coverage.packages(), x -> x.name(),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor, we can do MeasuredPackage::name instead of x -> x.name() and MeasuredFile::filename instead of x -> x.filename()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do. not really familiar with new java syntax, more of a scala guy myself :)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, I just don't like x variables and Intellij was kind/smart enough to suggest those :)

Comment on lines 334 to 337
{
ok = false;
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor, seems like this can be just ok = predicate.test(elem) && ok;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do, thank you, aligns well with what i did above.

assert new File(basedir, module + "/target/scoverage.xml").exists()
assert new File(basedir, module + "/target/site/scoverage/index.html").exists()
def entry = logText.find {
it.startsWith("scoverage-maven-plugin:") &&
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i've noticed that with maven 3.9.6 ( i have that one locally) this check fails, as seems like maven 3.9 changed format from [INFO] --- scoverage-maven-plugin:2.0.1-SNAPSHOT:check (default-cli) @ module01 ---
to [INFO] --- scoverage:2.0.1-SNAPSHOT:check (default-cli) @ module01 ---
so changing to it.startsWith("scoverage") && seems fine for both 3.9.x and 3.8.x

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do

Previously, it was only reported as such for min = 100.
Also, extract a coverage computation and logging method.
Along with existing overall coverage, add parameters for statement and
branch minima at the package and file level.
@kitbellew
Copy link
Contributor Author

@jozic all done, ptal. happy new year :)

Copy link
Collaborator

@jozic jozic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@kitbellew thanks for your contribution and for your patience during reviews and those almost 6 years :)

I see that @gslowikowski wanted to do some extra checks, but as he's no longer active we gonna move forward and merge/release this. We can always revisit things later if needed.

Happy New Year!

@jozic jozic merged commit 1f37dd0 into scoverage:master Jan 1, 2024
4 checks passed
@kitbellew kitbellew deleted the covmin branch January 1, 2024 02:13
@jozic
Copy link
Collaborator

jozic commented Jan 6, 2024

@kitbellew this is released in 2.0.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants