-
Notifications
You must be signed in to change notification settings - Fork 388
Collecting code coverage prevents all test discovery on net472 only #578
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
Comments
Disable code coverage since that's what keeps tests from running on net472. This works around coverlet-coverage/coverlet#578
@AArnott I don't see any issue on coverlet side for netfx... @bradwilson @onovotny sorry for the inconvenience....I need to attach and debug the reason why on netfx+coverlet lead xunit to fail the discovering of tests(weird no issue with netcoreapp)...is there a way(guide/docs) on how attach a debugger to |
@MarcoRossignoli The way I do it is add |
@AArnott not sure if it's related but if I change the order of test the behaviour is different...I wonder if the issue is how custom attribute interact with xunit for net472 context.
public class Samples
{
/// <summary>
/// Demonstrates that xunit [Fact] behavior is to invoke the test on an MTA thread.
/// </summary>
[Fact]
public async Task Fact_OnMTAThread()
{
var expectedApartment = RuntimeInformation.IsOSPlatform(OSPlatform.Windows) ? ApartmentState.MTA : ApartmentState.Unknown;
Assert.Equal(expectedApartment, Thread.CurrentThread.GetApartmentState());
await Task.Yield();
Assert.Equal(expectedApartment, Thread.CurrentThread.GetApartmentState());
}
/// <summary>
/// Demonstrates that the <see cref="UIFactAttribute"/> can run on all platforms,
/// and emulates a UI thread (not specific to WPF or WinForms) with a <see cref="SynchronizationContext"/>
/// that keeps yielding awaits on the original thread.
/// </summary>
[UIFact]
public async Task UIFact_OnSTAThread()
{
int initialThread = Environment.CurrentManagedThreadId;
Assert.NotNull(SynchronizationContext.Current);
var expectedApartment = RuntimeInformation.IsOSPlatform(OSPlatform.Windows) ? ApartmentState.STA : ApartmentState.Unknown;
Assert.Equal(expectedApartment, Thread.CurrentThread.GetApartmentState());
await Task.Yield();
Assert.Equal(initialThread, Environment.CurrentManagedThreadId);
Assert.NotNull(SynchronizationContext.Current);
} Coverage is the same but one test is found...I wonder if something goes wrong and process is killed or dead, this could explain empty collected file
|
If you run with test host log enabled you can also some difference for the two execution
No test run
One test run
|
@AArnott any news? |
I didn't realize you were waiting on me. It looked like you were calling out results of your investigation as you went. What would you like me to do to help? Reordering test methods isn't an acceptable workaround IMO. I mean, sure I could do that, but isn't this a general problem? |
Sure I'm not saying that, but I wonder if this strange behaviour ring a bell to you to help to understand better, coverlet only instrument asm adding some "register hit" static method on line and branches. |
OK, thanks. Ya, none of what you've discovered causes any root cause ideas to come to mind. |
Ok ok no prob, thank's. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I am seeing a similar issue. MS's coverage collector in VS enterprise/test sees the coverage just fine, but coverlet is "blind" to all coverage that should be available from a particular XUnit test project. It seems to be linked to a particular call to a dependency lib that starts a thread. I will work to create a simple repro sln. If anyone else is experiencing this, this link may help to use MS's collector in your pipeline to collect coverage data. This is my plan B. |
This would be great thx. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Open a new issue pls. |
will do. |
The issue might be out-dated because new releases are available. Please reopen the issue if the bug still exists and can be reproduced with latest preview from coverlet nightly build. |
This repros locally and in Azure Pipelines builds.
Notice how net472 runs 0 tests and reports:
While the netcoreapp targets report non-zero results:
In fact simply comparing the output of these two commands shows that the mere collection of code coverage is what blocks test discovery:
The text was updated successfully, but these errors were encountered: