Custom output filename for collector

[gix]

Running dotnet test --collect "XPlat Code Coverage" on a solution with multiple test projects and/or test projects with multiple target frameworks creates multiple coverage.cobertura.xml files without any easy way to relate those back to the test project/target framework. (Can VSTest do this itself?) The output of dotnet test contains this information, but it would be complicated to parse.

Since coverlet is providing the filename of the VSTest attachments, would it be possible to (optionally) include the assembly name and target framework? For example, with junit.testlogger I can use dotnet test --logger "junit;LogFilePath=TestResults.{assembly}.{framework}.xml and have those placeholders filled in.

[MarcoRossignoli]

Hi @gix,

we have it already for msbuild integration https://github.com/coverlet-coverage/coverlet/blob/master/src/coverlet.msbuild.tasks/ReportWriter.cs#L25

for the collector integration we need to check, but we should get it from the runsettings for the "current" run(in case of more tfms we'll run more time) https://docs.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2022#runconfiguration-element (TargetFrameworkVersion)

To be aligned with msbuild we should use it "always", we don't have a way to provide dynamic patterns, also we don't have a way to change the report filename, at the moment if I recall well is a concat of

DefaultFileName https://github.com/coverlet-coverage/coverlet/blob/master/src/coverlet.collector/Utilities/CoverletConstants.cs#L9
and report extension
https://github.com/coverlet-coverage/coverlet/blob/master/src/coverlet.core/Reporters/CoberturaReporter.cs#L20

Concat part https://github.com/coverlet-coverage/coverlet/blob/master/src/coverlet.collector/DataCollection/CoverageManager.cs#L110

I think that the first step would be align the behavior with msbuild.

Let me know if you're interested to take this contribution, not mandatory at all.

[daveMueller]

@MarcoRossignoli Can you elaborate this a bit? What if there is no runsettings file specified?

we should get it from the runsettings for the "current" run(in case of more tfms we'll run more time) https://docs.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2022#runconfiguration-element (TargetFrameworkVersion)

Can't we just also use coverlet.collector.targets like with MSBuild driver?

[MarcoRossignoli]

@daveMueller what you mean?

Target for collectors are used to inject coverlet path, but inside the collectors we don't have the current tfm running. I mean I'd don't see a way to flow the info inside the target to the datacollector that is the place where we generate the file.

There's always a runsettings generated "in memory" also if a user doesn't specify...that one contains the current tfm(and will merge with user config), the thing is that I think that inside the collector we don't have access to the whole config but only to our section and it's not clear if it's possible have access to it.

[daveMueller]

Ahh OK thanks I get it now. 👍

[daveMueller]

I created a PR with a prototype for this. Solutions can be discussed there #1299.

[github-actions]

This issue is stale because it has been open for 3 months with no activity.