`TestMethodIdentifierProperty.TypeName` isn't intended to contain parentheses

[Youssef1313]

https://github.com/thomhurst/TUnit/blob/57effa34626f1b58c37a10aa24d6d68c8ab00d62/TUnit.Engine/Extensions/TestExtensions.cs#L25-L32

https://github.com/thomhurst/TUnit/blob/57effa34626f1b58c37a10aa24d6d68c8ab00d62/TUnit.Core/Extensions/TestContextExtensions.cs#L54-L70

It looks like for the case of a test class with primary constructor and [Arguments] attribute, the arguments are added between parentheses after the type name.

This is not the intended usage of the API. I can see it was done this way to adjust how the hierarchy is displayed on Test Explorer, but the implementation violates the API contract and might break in future, and will likely break any custom extension that tries to read TestMethodIdentifierProperty and interprets it per the API contract.

Unfortunately, fixing this means that the display won't look the way you want it to be. I think the right approach there would be using the ParentTestNodeUid of TestNodeUpdateMessage but it's unfortunately not yet supported in (at least) VS Test Explorer (I don't know about Rider - if it doesn't work there, you can open a report to them). But still it won't work in VS. This is related to https://github.com/microsoft/testfx/issues/3371

[thomhurst]

Is there any update on custom control of the TE layout? I don't really want to fix this until something like that is ready. As mentioned in my comments on that issue, if I'm injecting different data at the class level, the TE will not show which is which. And that is going to be a bad experience for users.

[Youssef1313]

Is there any update on custom control of the TE layout?

I'd really love to have that done, but so far there are no updates there, unfortunately.

[thomhurst]

Is there any update on custom control of the TE layout?

I'd really love to have that done, but so far there are no updates there, unfortunately.

:(

Is there any way I, or other users, could raise or put our support behind an issue to the VS team to implement this? I may be naive but it doesn't look like a difficult task to me. The UI is already built to handle item > expand list > item > expand list etc.

All they'd need to do (unless I'm missing context) is map a new custom test node property containing the new path into that.

[Youssef1313]

I think best you can do is to open a request on https://developercommunity.visualstudio.com/, affected users can upvote it.

[thomhurst]

Thanks @Youssef1313 - I've raised this: https://developercommunity.visualstudio.com/t/Allow-test-frameworks-to-control-the-tes/10889052

[Youssef1313]

@thomhurst Note that there is a niche case where TUnit is already broken in TE today due to the expectations of how this property is expected to be used.

e.g (note the test class is in global namespace):

[Arguments("Hello.1")]
[Arguments("World.2")]
public class MoreTests(string title)
{
    [Test]
    public void ClassLevelDataRow()
    {
    }
}

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.