`AddTreeNodeFilterService` is not called by MSTest

[Youssef1313]

Amaury Levé (@Evangelink) Is it not supported by MSTest? Or is the call just missing?

AB#2332768

[Evangelink]

It would work only in the new platform mode but that's definitely possible to add. I would like to fix the command line naming first but although it's internal it would impact Tom Longhurst (@thomhurst) (would you be fine?), alternatively, we may be able to update the infra to change naming but allow registering extensions to change name (so that TUnit could keep current naming).

[thomhurst]

What are you changing the name to?

[Evangelink]

I haven't settled down on a naming but I am trying to enforce grouping by functionality (e.g. --report-XXX) so I would tend to think of someting like --filter-tree, --filter-node or --filter-path (for this last one I am afraid people would think it's disk path) but I am open to suggestions.

I don't like the fact we were forced to have --filter for the VSTest pattern. On v2, I hope we could change that --filter.

Side note, maybe we could try to repurpose the generic --filter to use some kind of prefix as routing mechanism. With VSTest, you can do things like TestCategory=... or FullyQualifiedName=..., maybe we could have Tree=....

[thomhurst]

If you change it as part of a major version, I can just bump TUnit a major version too.

Having consistent names is sensible to me.

As a workaround/side idea, maybe allow commands to be registered under multiple keys.

Would mitigate breaking changes like this, and also let you register using shorthand versions

E.g. --filter-tree / --ft / --treenode-filter

[Evangelink]

Having consistent names is sensible to me.

Great <3

As a workaround/side idea, maybe allow commands to be registered under multiple keys.

Interesting!

let you register using shorthand versions

Ratio problems/benefits has never been positive in my experience so I'd rather avoid shorthands.