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

Failed to get coverage result: Unable to read beyond the end of the stream #972

Closed
caghand opened this issue Oct 17, 2020 · 7 comments
Closed
Labels
as-designed Expected behaviour

Comments

@caghand
Copy link

caghand commented Oct 17, 2020

This is a follow-up to issue #718.
We are seeing this issue even when using the DataCollector integration ("XPlat Code Coverage").
But it only happens for a .csproj file that has 6500 tests. :)
And it happens once every 5 runs, approximately.

Our package versions:

  • Microsoft.NET.Test.Sdk: 16.7.1
  • coverlet.collector: 1.3.0
@fahadabdulaziz

This comment has been minimized.

@caghand
Copy link
Author

caghand commented Oct 18, 2020

@fahadabdulaziz, your situation is a known issue in the msbuild integration, addressed in issue #718. On the other hand, this particular issue is dedicated to investigating the same error in the DataCollector integration (without any msbuild integration).

@fahadabdulaziz
Copy link

@caghand oh thanks for clarifying that, and sorry for the interruption :-)

@MarcoRossignoli MarcoRossignoli added the waiting for customer Waiting for customer action label Oct 19, 2020
@MarcoRossignoli
Copy link
Collaborator

MarcoRossignoli commented Oct 19, 2020

@caghand is your project .NET Framework or .NET Core?

If .NET Framework this is expected, in process collectors won't be loaded so you'll hit same issue as msbuild, you can follow explaination here #970 we fixed this some days a go but not in a stable relase at the moment.
Can you try with tmp version(we got some issues with myget so I've uploaded master version on my unofficial coverlet feed https://f.feedz.io/marcorossignoli/coverletunofficial/nuget/index.json, use last version 3.0.0 preview.

@caghand
Copy link
Author

caghand commented Oct 19, 2020

Hi @MarcoRossignoli, our project is in .NET Core 3.1.
But we are not passing "XPlat Code Coverage" on the command line. We are passing it via a ".runsettings" file.
Our command line looks like this:
dotnet test <path_to_csproj_file> --no-build --verbosity normal --configuration "$(BuildConfiguration)" /property:Platform="$(BuildPlatform)" --settings test.runsettings
And test.runsettings contains a DataCollector element with friendlyName="XPlat Code Coverage".
Could this problem be happening because we are not passing "XPlat Code Coverage" on the command line?

@MarcoRossignoli
Copy link
Collaborator

MarcoRossignoli commented Oct 19, 2020

Could this problem be happening because we are not passing "XPlat Code Coverage" on the command line?

Yep without passing it to command line in process collector won't be injected(and you'll hit same issue as msbuild), we use runsettings only to pass parameters to coverlet.
This is second time I see this misuse in few days, can you file an issue on https://github.com/microsoft/vstest so I can understand how to fix?

It's on guide https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/VSTestIntegration.md but I think it isn't clear enough 😕 , let me know if we can improve it, or feel free to open a PR to "highlight" this fact.

@MarcoRossignoli MarcoRossignoli added as-designed Expected behaviour and removed waiting for customer Waiting for customer action labels Oct 19, 2020
@caghand
Copy link
Author

caghand commented Oct 19, 2020

Thanks for the info! I have filed an issue about it here: microsoft/vstest#2599 (I hope I explained it correctly there! :))
I think your documentation is pretty clear. And my first impression was just like you intended: The ".runsettings" file contains DataCollector settings, and the command-line contains which DataCollectors to activate. But then I noticed an unexpected behavior: I had an old "Code Coverage" element left over in my ".runsettings" file, and this caused dotnet test to collect legacy ".coverage" reports as well as Cobertura reports. And then I thought, "Hey, it looks like the '.runsettings' file actually contains the list of DataCollectors to activate, and the command-line parameter must be redundant. Let me avoid repeating the same 'magic string' in two places." And of course, this was a wrong conclusion.
After adding back the command-line parameter, we haven't seen this problem (so far), so I am closing this issue! :)

@caghand caghand closed this as completed Oct 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
as-designed Expected behaviour
Projects
None yet
Development

No branches or pull requests

3 participants