Inirit
commented
1 year ago Well I figured out what the problem was and it was not necessarily related to coverlet. It would take a lot to explain the entire situation, but the sort of short version is that our build output directory is composed entirely of symlinks but with a few files hard copied so that Coverlet could instrument them without polluting the original files that could be referenced by other build targets. However, the dotnet runtime was still resolving paths of dlls in this original physical location that the symlinks (replaced by hard copies) were pointing to due to the deps.json file associated with the test assembly still being a symlink. On Linux, the dotnet runtime resolves the realpath of this file (which fully resolves symlinks) and looks for dlls adjacent to that resolved path (I'm about 80% sure about this, would need to look through the runtime source code again). Coverlet would correctly instrument the hard copied files, but dotnet would load the untouched original files and therefore run tests without instrumentation and therefore without generating hit files.
The fix was to hard copy the deps.json file into the build output directory.
I'm running into a situation where the coverage results show 0 line hits. I know for sure this cannot be the case as my tests successfully execute, so there must be something else going on.
I'm aware of the Known Issues page which describes exactly what I'm observing: 0 line hits and a message in the diagnostic logs saying "Hits file:'X' not found for module: 'Y'". However, the solution says to use collectors which I already am. The command used to invoke the tests looks something like this:
dotnet test "MyTestAssembly.dll" --collect:"XPlat Code Coverage" --logger:"console;verbosity=detailed" --results-directory:"results" --TestAdapterPath:"PathToCoverletNuGetPackageFiles/build/netstandard1.0" --settings:"MyRunsettings.runsettings"
(A few things to note: I am working entirely outside of MSBuild and I'm invoking "dotnet test" against an already-built dll)
In the diagnostic logs for the dotnet testhost, these lines (which correspond to the only test that exists in the test project) seem possibly related but I don't know for sure:
The logs from the data collector that cover the time frame of the above logs:
Beyond this I'm not sure what else to look at to diagnose the problem.