Redesign of GUI Display

[CharliePoole]

I'm starting this issue as a discussion point for some potential major revisions to the GUI, inspired by an idea created by @rowo360. His proposal is shown below. I'll add my comments separately and probably create some sub-issues as well.

---

I propose that we drop the different DisplayStrategy classes and groupings! There’s only one single DisplayFormat and that’s the NUnit tree display. The hierarchy in this tree is specified by NUnit, so we’ll build up the tree always using the intrinsic NUnit parent of a node. Of course, the user should again have the option of customizing the view in this tree. For this purpose, I suggest that the user can specify which hierarchy levels he wants to be displayed:

Assembly
Namespace
Fixture 

If he enables all three hierarchy levels, it results in the NUnit tree. If he enables only the Fixture level, it’s the former FixtureList mode. And if he disabled all of them, it’s the former TestList mode. I first said that a node always uses its intrinsic NUnit parent, but the correct statement is: using its intrinsic parent or grandparent.

But nonetheless I expect that this kind of tree display is simple, because there are only these three settings which are controlling the tree hierarchy – nothing else!

I have also included the assembly and namespace here, as NUnit provides this information, but also because I think that we have been missing this so far.

One side note: the order of these hierarchy level is always fixed as NUnit provides it! I just want to show/hide the different hierarchy levels. (Visual Studio supports different order – which is strange in my opinion!)
Here’s a fake screenshot – the user can enable and combine different options:

Of course, we want to continue that the user can view his tests by outcome, duration and category – but I propose to do all of this by filters! So, the tree hierarchy remains always as described above, but only certain nodes are filtered out. If a node is filtered out, I propose to not show it in contrast to grey it out. And as usual with filters, if all children are filtered out, then the parent should also be removed.

Outcome:

I noticed for example that the R# test explorer doesn’t support an outcome grouping, but instead provides only an outcome filtering 😊

Currently with our grouping approach we are struggling where to place a Fixture node if it contains failed and passed test cases. And after some discussion we came up with the idea to place the Fixture node in both groups. With the filtering approach the Fixture node exists only once and will have his result state provided by Nunit. That’s seems to be much simpler!

Duration:

The filtering approach can also be applied for durations. We discussed and agreed that test durations should be considered on TestFixture level only. But I expect that will work with filters identically.

Category:

Originally, I hadn't thought about using filters for the categories. But after the above considerations, it just fits perfectly and it’s also almost identically to the category handling in TestCentric 1.X! In the past, we have often discussed with our Grouping approach when a category should be applied. For example: FixtureList mode and category defined on testcase level and we didn’t come up with a final solution yet. I hope that this will be solved by the filter approach automatically, because it’s an established approach from the past.

Here’s a fake screenshot with an idea about the UI for such a filtering:

I have the feeling that the UI for category filter might be somehow different than outcome and duration, because the list can be longer. Therefore, I placed this button ‘clear’ (button ‘set all’ might be also helpful) to indicate it.

The user can combine those filters: filter for all ‘passed’ tests which are running ‘slow’. I consider this combination of filters as a ‘AND’ operation. I don’t think it’s required that the user can define if the filters are combined with ‘OR’ or ‘AND’.

Something for the future: we can additionally provide a TextBox for filtering. So, the user can enter a Namespace/Fixture/Test name to filter his tests by name – just an idea.

Ok, I know a lot of stuff and I know that I propose to do some parts differently. Well, however my actual intention is not to make it differently, but to simplify it. 😊

Moreover, I think that these considerations don’t require a complete redesign, but fits quite well to the existing approaches.

Some benefits:

Separation between tree hierarchy and filter
No tree nodes for TestGroups anymore
No shifting of nodes within the tree based on outcome or duration during a test run
Each test node is present exactly once in the tree
Clear category handling

And regarding the general Filter implementation I could imagine that each TestNode just get an additional property IsVisible. This property is set while doing the Filtering and it’s accessed when building up the tree – all TestNode with IsVisible=false are simply omitted.

[CharliePoole]

@rowo360 Note the sub-issues I added

[CharliePoole]

@rowo360
Converting this issue to a discussion because the use of sub-issues for something so big as this didn't seem to work so well for me. This feature of GitHub is also new to me, so let's see how it works. The sub-issues we created are still there with their parent links pointing to the now-closed issue, which itself links here.

I'm not giving up on Sub-Issues entrirely, but I think this one was just too broad.