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

[BUG] Missing code coverage when there is logic that sets a default value for a parameter of a specific type #1640

Open
CristianBordeanFortech opened this issue Mar 12, 2024 · 3 comments
Labels
stale with repro Issue with repro

Comments

@CristianBordeanFortech
Copy link

Describe the bug
There is no code coverage in a Web project when there is logic that sets the default value for a parameter of type Microsoft.Extensions.DependencyInjection.ServiceLifetime.

To Reproduce
MissingCoverage.zip
I've attached a sample project where the issue can be reproduced. By removing the serviceLifetime default value from CheckLifetime code coverage works.

Expected behavior
To see project code coverage.

Actual behavior
The code coverage is simply missing in the project, there is no error, the test gets executed.

Configuration (please complete the following information):
The project is written in .NET 6, the tests project has coverlet.collector 6.0.0. My machine is running on Windows 11. The issue is not specific to this configurations.

Additional context
The code that breaks coverage doesn't needs to be used. I've also tried switching to other types and was not able to reproduce this.

@github-actions github-actions bot added the untriaged To be investigated label Mar 12, 2024
@daveMueller
Copy link
Collaborator

Thanks for reporting and thanks for the repro. When enabling the log it can be seen that it is the same issue as #1102. The assembly Microsoft.Extensions.DependencyInjection.Abstractions, Version=6.0.0.0, can't be resolved.

To get coverage with the collector in your repro I had to do two things. Add PreserveCompilationContext to the assembly under test.

MissingCoverage.Host.csproj

<Project Sdk="Microsoft.NET.Sdk.Web">
	<PropertyGroup>
            <TargetFramework>net6.0</TargetFramework>
	    <PreserveCompilationContext>true</PreserveCompilationContext>
        </PropertyGroup>
</Project>

And additionally upgrade to coverlet.collector 6.0.1 as we made some improvements to the assembly resolver in this version.

grafik

@daveMueller daveMueller added with repro Issue with repro and removed untriaged To be investigated labels Mar 12, 2024
@CristianBordeanFortech
Copy link
Author

CristianBordeanFortech commented Mar 13, 2024

@daveMueller, thanks for having a look in such a short time and providing a solution. What you suggested worked.
The one thing that I don't understand though is why there is a difference if serviceLifetime has a default value or not. If that assembly causes the issue there shouldn't be any difference, no?

@NickBranstein
Copy link

@daveMueller, thanks for having a look in such a short time and providing a solution. What you suggested worked. The one thing that I don't understand though is why there is a difference if serviceLifetime has a default value or not. If that assembly causes the issue there shouldn't be any difference, no?

Thanks so much for this - you saved us a ton of headaches. Interestingly enough this works fine for us on 6.0.0 when removing that default parameter. Interesting tidbit, this didn't start happening for us until we upgraded to dotnet 8.

@github-actions github-actions bot added the stale label Jul 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale with repro Issue with repro
Projects
None yet
Development

No branches or pull requests

3 participants