-
Notifications
You must be signed in to change notification settings - Fork 998
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
Testing all WinForms controls have unit tests coverage #10476
Testing all WinForms controls have unit tests coverage #10476
Conversation
@sharwell - do you have any recommendations on how to re-enable code coverage, or sample repos we could take a look at? |
I've done this in a few repo using https://github.com/microsoft/codecoverage/. E.g., dotnet/aspire#569. |
My recommendation would be to follow https://github.com/dotnet/roslyn-analyzers/, using coverlet, ReportGenerator, and codecov.io. At this time I cannot recommend the use of microsoft/codecoverage due to its licensing policy and lack of benefits over the more permissive/open/well-established packages which I recommend instead. |
@sharwell why are you suggesting to use 3P service (i.e., codecov.io) over using the MS services? This implies sending data to 3P. /cc: @jakubch1 |
I haven't seen any 1P service that works in this space. Specifically, all 1P services that I've observed focus on the code coverage for the repository as a whole, a largely irrelevant feature. The single highest-value code coverage feature which any system must implement to even be considered viable is allowing a pull request reviewer to see the code coverage impact of that pull request. This includes the following two items:
This behavior aids code reviewers in asking smart questions about complex sections of code which are being reviewed, such as seeing scenario tests that cover special cases, or asking why a special case in code isn't being covered. Special cases in code are more likely to be the source of a regression because they are less likely to be hit in the common case.
It's not open source, but there are other open-source alternatives which have been around longer and perform just as well. I can't condone choosing a closed ecosystem without clear benefits. |
src/Microsoft.VisualBasic.Forms/tests/UnitTests/Microsoft.VisualBasic.Forms.Tests.vbproj
Outdated
Show resolved
Hide resolved
8a55641
to
fd178b0
Compare
The removal of codecov.io upload is highly unfortunate. I've found the Azure Pipelines code coverage features lacking to the point of basically useless. I have no objection to publishing in both locations, but if the data only goes to one location it should be codecov.io. |
OK, I've added this task back. |
@SimonZhao888 - Would it make sense to split this PR into 2 PRs or 2 commits. First do a cleanup and refactoring tasks, and then enable the code coverage? It will be easier to review and maintain this way. This is what Sam did with his big PR - #10552 |
I may be able to help with it as well once the integration test changes are completed. |
eng/pipelines/build.yml
Outdated
condition: and(eq(variables['_BuildConfig'], 'Debug'), eq('${{ parameters.targetArchitecture }}', 'x64')) | ||
|
||
#Publish code coverage results | ||
- task: PublishCodeCoverageResults@1 |
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.
We have PR and CI builds in GH, and in the internal AzDO repo. Where is this task executed?
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.
Since PublishCodeCoverageResults@1 is an AzDO internal task, I assume it will be executed at AzDO.
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 can't tell if this is asking about GitHub Actions vs Azure Pipelines, or if it's asking about Azure Pipelines public build vs Azure Pipelines internal/signed build. I do know this file is only active in Azure Pipelines builds, but not sure if it's running in the internal/signed build.
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.
Hi @sharwell,
Could you please help me with a question?
Now we are going to count the code coverage of all the automated tests, I am checking the coverage results on CodeCov server, but found that the results counted on CodeCov server are much different from the results on Azure pipeline, I am not sure if I am missing any settings, Could you please point them out for me?
Pipeline link: codecoverage-tab
CodeCov link: CodeCov-codecoverage
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.
Now we are going to count the code coverage of all the automated tests
Yes, this is hugely beneficial in identifying certain categories of accidental bugs and/or behavior changes.
I am checking the coverage results on CodeCov server, but found that the results counted on CodeCov server are much different from the results on Azure pipeline
I noticed the same. I was planning to make some tweaks either after you are ready for final review/merge or after it merges. Once you reach a stable point I can go over those details with you.
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.
Items I'm planning to verify later (could be part of this PR or separate):
- Ensure we only upload exactly one coverage report to codecov.io for a single PR submission. Historically (talking 2+ years ago), codecov.io internally was not efficient at merging multiple reports, which could cause problems for large repositories. I found that merging the reports before submitting them significantly improved response times and reliability.
- Review behavior for production code (make sure it appears, check status for flags)
- Review behavior for test code (make sure it appears)
- Review behavior for build-time generated code, see if there is any way to make it appear in tools
- Make sure the codecov.io comment is appearing in PRs. It's already configured to appear but hasn't in this PR for some unknown reason.
The first item is the most important. During my work for this item, I'll be comparing the behavior of WinForms with the behavior of dotnet/roslyn-analyzers (uses coverlet+Arcade which we want to match) and DotNetAnalyzers/StyleCopAnalyzers (uses OpenCover but has a proper Publish Code Coverage stage that I can model after if we need it).
...mitives/tests/TestUtilities.Tests/System.Windows.Forms.Primitives.TestUtilities.Tests.csproj
Outdated
Show resolved
Hide resolved
Will a diff between coverage before the PR and coverage after the PR be published when PR build completes? |
That is the expectation. It's not clear yet why it's not showing up in this repository, but you can see it in action here: At the time of this comment, it says there are 38 lines changed in my linked PR which are not fully covered, out of a total of around 400 LOC touched by the PR. |
I'll double-check the differences in these two pipelines to enable the feature in codecov.io. |
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.
Thank you! Make sure to squash-merge this PR!
Feel free to do that in the next PR. |
f6b8649
@@ -20,16 +20,29 @@ flags: # which files to include in the reporting | |||
production: | |||
paths: | |||
- src/Common/src/ | |||
- src/Microsoft.VisualBasic/src/ | |||
- src/Microsoft.VisualBasic.Forms/src/ | |||
- src/System.Design/src/ | |||
- src/System.Drawing/src/ |
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.
We don't have to include System.Design and Drawing into reporting, do we still need it here?
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.
The changes here are mainly for Codecov.io, if, however, they are not needed, I will remove them in the PR adapted to Codecov.io.
Fixes #10453
Proposed changes
Customer Impact
Regression?
Risk
-Yes
Screenshots
Test methodology
Microsoft Reviewers: Open in CodeFlow