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

Testing all WinForms controls have unit tests coverage #10476

Merged
merged 27 commits into from
Jan 10, 2024

Conversation

SimonZhao888
Copy link
Member

@SimonZhao888 SimonZhao888 commented Dec 14, 2023

Fixes #10453

Proposed changes

  • Enable code coverage on public PR builds.

Customer Impact

  • No

Regression?

  • No

Risk

-Yes

Screenshots

image
image

Test methodology

Microsoft Reviewers: Open in CodeFlow

@ghost ghost assigned SimonZhao888 Dec 14, 2023
@ghost ghost added the draft draft PR label Dec 14, 2023
@Tanya-Solyanik
Copy link
Member

@sharwell - do you have any recommendations on how to re-enable code coverage, or sample repos we could take a look at?

@RussKie
Copy link
Member

RussKie commented Dec 17, 2023

I've done this in a few repo using https://github.com/microsoft/codecoverage/. E.g., dotnet/aspire#569.
Please ping me if you have any questions or need help.

@sharwell
Copy link
Member

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.

@RussKie
Copy link
Member

RussKie commented Dec 19, 2023

My recommendation would be to follow 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.
Also, what is the problem with microsoft/codecoverage licensing?

/cc: @jakubch1

@sharwell
Copy link
Member

sharwell commented Dec 19, 2023

why are you suggesting to use 3P service (i.e., codecov.io) over using the MS services?

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:

  1. (Most important) Show the code coverage of the lines of code changed by that pull request
  2. (Secondary) Show the changes to code coverage occurring on lines of code not touched by that pull request

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.

Also, what is the problem with microsoft/codecoverage licensing?

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.

eng/MergeCoverageData.ps1 Outdated Show resolved Hide resolved
eng/pipelines/build.yml Outdated Show resolved Hide resolved
eng/pipelines/build.yml Outdated Show resolved Hide resolved
eng/MergeCoverageData.ps1 Outdated Show resolved Hide resolved
eng/MergeCoverageData.ps1 Outdated Show resolved Hide resolved
@sharwell
Copy link
Member

sharwell commented Dec 28, 2023

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.

@Tanya-Solyanik Tanya-Solyanik added the 📭 waiting-author-feedback The team requires more information from the author label Dec 31, 2023
@ghost ghost removed the 📭 waiting-author-feedback The team requires more information from the author label Jan 2, 2024
@SimonZhao888
Copy link
Member Author

but if the data only goes to one location it should be codecov.io.

OK, I've added this task back.

@Tanya-Solyanik
Copy link
Member

@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

@sharwell
Copy link
Member

sharwell commented Jan 2, 2024

I may be able to help with it as well once the integration test changes are completed.

eng/MergeCoverageData.ps1 Outdated Show resolved Hide resolved
condition: and(eq(variables['_BuildConfig'], 'Debug'), eq('${{ parameters.targetArchitecture }}', 'x64'))

#Publish code coverage results
- task: PublishCodeCoverageResults@1
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

@sharwell sharwell Jan 4, 2024

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.

Copy link
Member Author

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
image

Copy link
Member

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.

Copy link
Member

@sharwell sharwell Jan 5, 2024

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).

@Tanya-Solyanik
Copy link
Member

Will a diff between coverage before the PR and coverage after the PR be published when PR build completes?

@sharwell
Copy link
Member

sharwell commented Jan 8, 2024

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:
dotnet/roslyn-analyzers#7116

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.

@SimonZhao888
Copy link
Member Author

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:
dotnet/roslyn-analyzers#7116

I'll double-check the differences in these two pipelines to enable the feature in codecov.io.

Tanya-Solyanik
Tanya-Solyanik previously approved these changes Jan 9, 2024
Copy link
Member

@Tanya-Solyanik Tanya-Solyanik left a 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!

@Tanya-Solyanik
Copy link
Member

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:
dotnet/roslyn-analyzers#7116

I'll double-check the differences in these two pipelines to enable the feature in codecov.io.

Feel free to do that in the next PR.

JeremyKuhne
JeremyKuhne previously approved these changes Jan 9, 2024
lonitra
lonitra previously approved these changes Jan 9, 2024
@@ -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/
Copy link
Member

@Tanya-Solyanik Tanya-Solyanik Jan 10, 2024

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?

Copy link
Member Author

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.

@SimonZhao888 SimonZhao888 merged commit 41e805c into dotnet:main Jan 10, 2024
9 checks passed
@ghost ghost added this to the 9.0 Preview1 milestone Jan 10, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Feb 9, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ensure that all WinForms controls have unit tests coverage for public APIs
7 participants