Generic Filter expressions for NUnit tree

[CharliePoole]

So far we have discussed specific filters. But NUnit itself supports a general filter using the --where option of the console runner. The framework knows how to deal with the filters created by this option - (I wrote the parser)

Do we want this sort of functionality for the GUI? A command-line option does not seem very useful. Howe would we expose it the feature?

Decisions:

• Decide if we want this
• Decide how the user would activate it in the GUI
• Decide how it would display in the tree
• Decide what happens to the run commands if a filter is active.

[rowo360]

Here is an idea of how we could support the general NUnit filter:
First of all, I think that the existing filter functionality already supports a wide range of use cases. So I hope and expect that the majority of users won't miss anything.
But nonetheless the NUnit filter supports more use cases and some power users will notice the gap. So we should try to support them also. But my idea is that we don't create a new UI to configure this filter - that might be too tough to add UI elements to configure all those operators and expressions. Instead we can use the existing text filtering textbox for this purpose.
My consideration is, if almost only power users use this, then they also know the syntax of the NUnit filter.

Here's a screenshot how this might look like:

For example we might add a dropdown box at the end of the filter textbox. It can be used to select the filter mode: Text or NUnit. And of course we can guide the user with some Tooltips. But I hope that it's self-explanatory.

I imagine that the filtering itself can be performed by a Runner.Explore(testfilter) call. This call will return a XmlNode/TestNode which can be used to get a list of IDs which are matching the filter.
This idea would fit very well to the existing filtering (regarding display in tree and also to the run command when filter is active).

One drawback of this idea: the user can edit incorrect syntax of the filter statement. We must deal with this incorrect syntax somehow, provide some feedback and decide how to filter the tree in this case...