-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Add unit test coverage requirements for some packages #22401
Add unit test coverage requirements for some packages #22401
Conversation
I think this should use the merged results. Currently it only uses the integration test result. |
Done |
Now we see that it works. But it looks like our code calculates the coverage different than CodeCov. |
yes, For those slight differences, I think it's accepted. |
Looks like CodeCov combines the results of the subdirectories. Our calculation displays the result for the files in that directory only (?). That would explain the NaN% lines. |
I would lower the current requirements to match what we have atm ... and then do increase them by case |
I forsee some PR friction if we add this. I'd guess more PRs than usual would become abandoned with such strict requirements as not every bug fix is easily testable. We can try, but I guess there should be a mechanism for a owner to overrule this requirement for individual PRs. |
Is it the right way to go? |
I think in worst case we can lower the number for a fix in that pull ... but we should enforce it ... we want good tested code |
I agree to improve test code (when I review, I frequently suggest to add tests ...) But, is it the right way to go? Filling the Makefile with a lot of percentage numbers? |
we could improve the tool that checks it and add a new .min_coverage.conf or something like that witch do contain the threashhold |
A clear Makefile could L-G-T-M |
7ffa15c
to
495eb4a
Compare
if err != nil { | ||
log.Fatalf("invalid percent: %s", percent) | ||
} | ||
return int64(i * 10) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why i*10
? 12.34%
means "123"? That's a strange unit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some output will be 12.3%
, and I think it's accurate enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say this trick is difficult to understand, and I do not understand why it must be casted to int64
IMO keep the original float "12.3" is clear enough, or unify the unit to natural unit (1.0 mean 100%, 0.02 mean 2%)
Will there be an option to ignore reduced coverage? Like when some stuff is hard/impossible to test for, e.g. admin should still be able to merge. Generally, I'm -0 on this topic, as it may hinder contribution. |
go-version: ">=1.20" | ||
check-latest: true | ||
- uses: actions/download-artifact@v3 | ||
- run: go run build/gocoverage.go merge unit-test-coverage/coverage.out unit-test-coverage-gogit/coverage.out unit-test-coverage-integration/coverage.out > coverage.all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Calls like this should be in the Makefile so that coverage can be produced locally as well. Please don't lock us in into actions with commands like this.
Looks like we need to ask contributors to provide tests case by case. But should always encourage tests in PR. |
Yes, I'm always asking where possible, I think it's the best we can do. Strict requirements will not work so good I guess. |
This PR add a CI check for package tests coverage. When the coverage is less than a previous value, CI will be failure.