Incorrect Code coverage reporting for C# Object Initializers
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- csharp
- Domain
- testing-qa
Research direction
Start by reproducing the reported object and collection initializer pattern and its explicit-assignment equivalent with vstest.console 17.14.0-release-25203-01 and 18.0.1-release-25520-05. Compare the resulting coverage reports; done means the initializer statements are reported as covered when the code path is fully executed, or the limitation and workaround are documented.
Written by the indexing model from the issue text.
Description
We are running into an issue where code coverage reports incorrect or partial coverage for certain C# object/collection initializer patterns, even though the code path is fully executed.
Specifically, the following initializer-style pattern is not fully recognized by the coverage tool:
var thing = new Example
{
name = "object one",
[1] = '1',
[2] = '4',
[3] = '9',
Size = Math.PI,
['C', 4] = "Middle C"
};
To investigate, I ran the impacted tests locally using two versions of vstest.console:
17.14.0-release-25203-01
18.0.1-release-25520-05
In both cases, the coverage results remained unchanged, which suggests this is not resolved by upgrading the test runner.
What we’ve observed is that rewriting the same logic using explicit assignments (instead of initializer-style patterns) results in correct coverage being reported. For example, the following pattern is correctly recognized by the coverage tool:
var thing = new Example();
thing.name = "object one";
thing[1] = '1';
thing[2] = '4';
thing[3] = '9';
thing.Size = Math.PI;
thing['C', 4] = "Middle C";
Based on this, it appears to be a limitation or bug in how the underlying coverage engine handles certain object/collection initializer patterns, rather than an issue with our pipeline or configuration.
If this is a known limitation, or if there is a recommended workaround or escalation path, guidance would be appreciated.
Thanks!
- Dominant language
- C#
- Stars
- 125
- Forks
- 17
- Avg merge
- 1h 17m
- Merged PRs (30d)
- 2
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/codecoverage
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
microsoft/codecoverage#246 · 6 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
microsoft/codecoverage#237 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
microsoft/codecoverage#234 · 1 comment · 2 reactions ·
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
microsoft/codecoverage#233 · 2 reactions ·
-
Difficulty 5/5 Over a week Newbie friendliness 28/100
microsoft/codecoverage#232 · 6 comments ·
All issues in microsoft/codecoverage
Similar issues
-
type/automation type/tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
t/bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
ci-failure-cause test-failure
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
area:auth FE mvp P3
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
klasolsson81/jobbliggaren#1788 ·