[BUG] Generic methods are not correct translated

[mischube]

Describe the bug
I got some C# classes that have 2 methods with the same signature. One has a generic return value and one a fix type. So the outcoming cobertura report has the same function twice which leads to an error in our CI.

To Reproduce
I created a fresh c# library project with this class and a unit test project:

public class Class1
{
    public object GetObject()
    {
        return new object();
    }
    
    public T GetObject<T>() where T : new()
    {
        return new T();
    }
}

Created a github repo:
https://github.com/mischube/CoverletGenericIssue

Expected behavior

The generic method should have either a different name or signature

Actual behavior

Both methods have the same identifier.

Configuration (please complete the following information):

* Coverlet: Coverlet.Collector 6.0.0 / 6.0.2
* .NET-SDK 8.0.401
* .NET-Runtime 8.0.8
* WIN 11
* Dont think it is configuration related

Additional context

Seems to be similar to #1077

[Bertk]

Please refine the version information for .NET SDK/runtime e.g. 8.0.108 or 8.0.8

[mischube]

Sorry for the late answer. Somehow i missed the notification..
Added the detailed version

[Bertk]

Sorry, I cannot reproduce the issue. Please add information how you create the the XML snipped (coverlet.collector v6.0.2). The method names did not change but the result looks different.

I used dotnet test --collect:"XPlat Code Coverage and got this cobertura result:

<?xml version="1.0" encoding="utf-8"?>
<coverage line-rate="1" branch-rate="1" version="1.9" timestamp="1727685297" lines-covered="6" lines-valid="6" branches-covered="0" branches-valid="0">
  <sources>
    <source>C:\</source>
  </sources>
  <packages>
    <package name="CoverletGenericIssue" line-rate="1" branch-rate="1" complexity="2">
      <classes>
        <class name="CoverletGenericIssue.Class1" filename="GitHub\coverlet-issue-1691\CoverletGenericIssue\Class1.cs" line-rate="1" branch-rate="1" complexity="2">
          <methods>
            <method name="GetObject" signature="()" line-rate="1" branch-rate="1" complexity="1">
              <lines>
                <line number="6" hits="1" branch="False" />
                <line number="7" hits="1" branch="False" />
                <line number="8" hits="1" branch="False" />
              </lines>
            </method>
            <method name="GetObject" signature="()" line-rate="1" branch-rate="1" complexity="1">
              <lines>
                <line number="11" hits="1" branch="False" />
                <line number="12" hits="1" branch="False" />
                <line number="13" hits="1" branch="False" />
              </lines>
            </method>
          </methods>
          <lines>
            <line number="6" hits="1" branch="False" />
            <line number="7" hits="1" branch="False" />
            <line number="8" hits="1" branch="False" />
            <line number="11" hits="1" branch="False" />
            <line number="12" hits="1" branch="False" />
            <line number="13" hits="1" branch="False" />
          </lines>
        </class>
      </classes>
    </package>
  </packages>
</coverage>

[mischube]

both "GetObject" methods have the same signature in your result and thats the same result as mine and the key problem here. Since they are different methods, they should also have a different signature. In other words the generic parameter should be taken into account.

This case (2 methods with same signature) causes problems in our CI pipeline

#1077 was the same issue but on class level.

[Bertk]

Test coverage is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are.

I am not sure whether this is an issue because line coverage and condition branch coverage is checked.

[mischube]

These 2 methods are independent of each other and can do different things. I think the coverage report should reflect this.

[Bertk]

The coverage report has results for line numbers of both methods.

[mischube]

Well if you say it is good as it is, you can close this ticket