[BUG] Grouped TestCase test methods show full namespace and class name

[jacobcarpenter]

Describe the Issue

NUnit has a TestCaseAttribute (reference) to support parameterizing the same test with multiple inputs.

C# Dev Kit does support these tests in the Testing panel, and even helpfully groups them together.

However, the displayed name for the grouping parent is prefixed by the full namespace and class name. In a narrow view, this renders the grouping extremely unhelpful, since all the tests look like the same name. It also adversely influences the sort order:

Once you expand the grouping, the names underneath are reasonable/helpful:

It seems like xUnit theories (TheoryAttribute) are a similar concept. I do not know if they are similarly affected.

Steps To Reproduce

1. In an NUnit test project, declare a test using the [TestCase] attribute. It must have at least two rows (otherwise it will not be grouped):

[TestCase(1, 1, 2)]
[TestCase(1, 2, 3)]
public void VerifyAddition(int augend, int addend, int sum)
{
    Assert.That(augend + addend, Is.EqualTo(sum));
}

2. Build the project and refresh the Testing panel
3. Observe that the displayed grouping name in the testing panel is prefixed by the namespace and class.

Expected Behavior

I would like the displayed grouping names to not include the full namespace and class name as a prefix.

Environment Information

• OS: macOS
• VS Code Version: 1.82.2 (Universal)
• Extension Version: v0.4.10

[julioct]

Yes please, even in a very simple test suite tests are not readable from the very start:

Notice how the namespace shows at two levels and then it shows again for every single test case.

To see the actual test names you have to expand the panel a lot, which is not useful:

Can we simplify the tree view so that it shows like this:

• Namespace
  • Test Class
    - Test Case 1
    - Test Case 2
    - Test Case 3

Would make things much easier!

[knumat]

I can confirm that this issue also affects xUnit test cases defined with Theory/InlineData attributes in the Test Explorer panel in VS Code.

By default, both [Fact] and [Theory] tests show the full namespace/class in Test Explorer in VS Code. This is WAY too much text, even for small projects. For example:

Assembly
  Namespace
    TestClass
      Namespace.TestClass.OneFact
      Namespace.TestClass.AnotherFact
      Namespace.TestClass.Theory
        Namespace.TestClass.Theory(param: value1)
        Namespace.TestClass.Theory(param: value2)

Fortunately, there is an xUnit configuration option to only show the method names - create xunit.runner.json with "methodDisplay": "method" and deploy it in your .csproj file (see docs here). This cleans up the Test Explorer display for [Fact] tests, but grouped [Theory] tests still show the full namespace/class, as described in the original bug report from @jacobcarpenter at the top. For example:

Assembly
  Namespace
    TestClass
      OneFact
      AnotherFact
      Namespace.TestClass.Theory    <-- Here is the issue
        Theory(param: value1)
        Theory(param: value2)

Interestingly, this issue also affects the Test Explorer pane in full Visual Studio (or at least it did in 2020).
xunit/xunit#2122

The new Test Explorer for VS Code is great except for this issue. Hopefully someone can clean this up quickly!

[bradwilson]

@knumat This doesn't surprise me, as we (xUnit.net) report multiple tests for the same method, so it's likely using the method name (with the namespace'd class) as the grouping point. Our methodDisplay setting only affects the display name of the test itself, and there's no way that I'm aware of for us to influence the grouping that the UI is doing here. It does feel unnecessarily verbose, given that the current grouping already tells you the namespace and the class (further up the tree).

[knumat]

Yep, it's clearly a UI issue, as the .NET Core Test Explorer extension does not have this issue. It never prefixes the test name with the namespace/class, so it is easy to find the test case you are looking for.

[peterwald]

This has been fixed and should be available in the next pre-release version that ships.

[erjok]

I observe the same problem in Visual Studio 17.12.4

[knumat]

@erjok This issue has existed in Visual Studio for a while (see xunit/xunit#2122 ). You would need to contact Microsoft if you want them to update Visual Studio.