`AddTreeNodeFilterService` is not called by MSTest

[Youssef1313]

@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 @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.