Alternative NUnit Tree Displays

[CharliePoole]

In @rowo360 's proposal, uses the term "filter" to refer to both the type's of nodes displayed in the NUnit Tree and the various other filtering options such as filtering by category.

I think these are different in kind and usage, so I'm reserving the term "filter" for things like category, outcome, duration, etc. and calling the displays with or without namespaces (for example just "alternative displays". They are a bit like strategies but simpler.

Things we need to discuss and decide here include...

• Is it sufficient to hide assembly, namespace and fixture nodes? What about other types of nodes...
  • Parameterized Test Methods
  • Generic Test Methods
  • Projects
• Are all combinations possible / desirable?
• Should we combine namespaces if a namespace has only one child namespace? Is this an option or something we just do?
• Do we treat namespaces with SetUpFixtures differently from others?
• Do we need new images for different node types?
• Exactly what should the UI look like to do all of this?

[rowo360]

Is it sufficient to hide assembly, namespace and fixture nodes? What about other types of nodes...

I am probably influenced by the existing test explorers and only had assembly, namespace and fixture nodes in my mind. It's good that you mention additional cases! For example hiding test methods (regular, generic or parameterized) - that would significally reduce the entire tree by dropping all its leaves. Maybe a user is not that interested in all those details, but just need an overview? That might be ok as long as all tests passes, but I expect that some details are required as soon as a test starts to fail. At the moment, this option (hiding test methods) seems very foreign to me, so I would not support it now. Instead some intelligent 'Expand/Collapse' feature could also help: "Expand to all Fixtures" The same applies to the option 'hide all parameterized test methods' or 'hide all generic test methods' - I would not go for those now.

Instead I think in another direction by considering if we really need to support show/hide of Fixtures? Or if it's sufficient if we always show the Fixtures? Fixtures and test cases are the core of your tests, so I can argue that they should always be visible. Maybe you noticed already in the past that I'm not that big supporter of the 'TestList' mode - the resulting list of test cases is just a long list without any orientation for me. But that's only my opinion and we can continue to support it, because I don't expect any negative effects by this mode.

Project node: Do you mean the TestCentric project? Well, in that case it's the root node of the tree with contains the different assembly tree nodes as children. From my point of view we can continue to not show this node and don't need an option for it.

Are all combinations possible / desirable?

If we keep going on only with this three options (assembly, namespace and fixture) we can support all kind of combinations of them.

Should we combine namespaces if a namespace has only one child namespace? Is this an option or something we just do?

I would love to fold such namespaces together in one single tree node! When having a deep namespace hierarchy I always need to skip over the first nodes in my mind myself. That would be really simplified if we combine these. And I wouldn't control this behavior with an option, but just do it!

Do we treat namespaces with SetUpFixtures differently from others?

Thanks for mentioning SetUpFixtures ! I think I might have forgotten this case, but it's an important test case! I would keep the SetUpFixtures hidden for the user in the tree. So if a namespace only contains a SetUpFixture node, I would consider this namespace as empty.

Do we need new images for different node types?

That would be a cool visual effect! And in addition we would use the same images in the menu so that there's a clear relationship between them! I did a quick google search if it's possible to show two icons in a tree node at all (outcome and node type)? Yes it is - it's the general approach to customize the drawing of a treeview (TreeView.DrawNode Event). With this approach you can customize any visual aspect, but you are also responsible for everything on your own. So I would have to try a few experiments to be able to better assess this. But honestly, I can well imagine that this is quite a lot of work and that's why I would postpone it for the time being.

Exactly what should the UI look like to do all of this?

I propose to add a submenu to the NUnit strategy for the different options:

These menu items can be disabled as long as the NUnit Display format is not active. If, in the end, we realize that we no longer need the other two strategies + groupings, these sub menu items can be 'promoted' on level up.

[CharliePoole]

@rowo360 wrote:

Is it sufficient to hide assembly, namespace and fixture nodes? What about other types of nodes...

I am probably influenced by the existing test explorers and only had assembly, namespace and fixture nodes in my mind. It's good that you mention additional cases! For example hiding test methods (regular, generic or parameterized) - that would significally reduce the entire tree by dropping all its leaves.

Hiding all test methods isn't what I suggested. For non-parameterized, non-generic methods, there is only one test case per method, so the test method and test case are the same node. In all of this, I assume that the test cases would be collapsed or expanded by the user in the normal way. How they are displayed initially is a detail for implementation.

On the other hand... parameterized and generic methods introduce an intermediate node between the fixture and the individual test cases. I prefer to always see those nodes myself, but I'm trying to create a sort of specification here, so we should be complete about this.

Instead I think in another direction by considering if we really need to support show/hide of Fixtures? Or if it's sufficient if we always show the Fixtures? Fixtures and test cases are the core of your tests, so I can argue that they should always be visible. Maybe you noticed already in the past that I'm not that big supporter of the 'TestList' mode - the resulting list of test cases is just a long list without any orientation for me. But that's only my opinion and we can continue to support it, because I don't expect any negative effects by this mode.

I agree wrt fixtures. The old NUnit had a choice of the full tree or a list of fixtures as well. Regarding... support it in case it's needed... I think it's better to only introduce features we believe are needed. If people want more, they will ask. OTOH if we add a feature used by only a few people, we have to keep it and support it indefinitely to avoid breaking changes. So we should be conservative in choosing what new things to add.

Project node: Do you mean the TestCentric project? Well, in that case it's the root node of the tree with contains the different assembly tree nodes as children. From my point of view we can continue to not show this node and don't need an option for it.

No, I mean projects like NUnit projects (.nunit) and VS projects (.csproj, etc. and .sln). It may be we are not currently showing nodes for them. It was an issue at one time and may not yet be resolved. Projects are at a higher level then assemblies, of course.

(Stopping here since it covers all about one design question I raised. If we keep comments limited, there is more possibility (I think) of others joining in the discussion about a particular issue and it gives us a place to make a decision, close a question and possibly crate an issue to implement a single change.

[CharliePoole]

@rowo360 Commented

Are all combinations possible / desirable?

If we keep going on only with this three options (assembly, namespace and fixture) we can support all kind of combinations of them.

I guess they are all possible. That includes listing fixtures across multiple assemblies without listing the assembly, which doesn't seem like a good idea to me since you can have identically named fixtures in several assemblies.

From earlier discussion, we talked about always showing the fixtures as well. So... considering only the three options, I would lean toward supporting...

• Assembly + Namespaces + Fixtures (i.e. the current NUnit tree)
• Assembly + Fixtures

That's significantly less than the eight options possible by combining all three. :-) What do you think? Once we have decided on this we can update the projected UI to match it and create an implementation issue.

BTW, the above would need to be updated if we are dealing with project nodes, but I think if we always show assemblies, then we always show the projects above them as well.

[CharliePoole]

Should we combine namespaces if a namespace has only one child namespace? Is this an option or something we just do?

I would love to fold such namespaces together in one single tree node! When having a deep namespace hierarchy I always need to skip over the first nodes in my mind myself. That would be really simplified if we combine these. And I wouldn't control this behavior with an option, but just do it!

Yes "fold" is the word I was searching for! I assume we only fold if there is just a single sub-namespace under the namespace.

Would you create an enhancement issue for this? It should be a sub-issue to this one.

[CharliePoole]

Do we treat namespaces with SetUpFixtures differently from others?

Thanks for mentioning SetUpFixtures ! I think I might have forgotten this case, but it's an important test case! I would keep the SetUpFixtures hidden for the user in the tree. So if a namespace only contains a SetUpFixture node, I would consider this namespace as empty.

Agreed. Of course, an empty namespace with a SetUpFixture is very strange and possibly an error. That is, the user may have intended the SetUpFixture to affect some tests but put it in the wrong place. However, that's not our problem but NUnit's. :-)

OTOH we want to handle very well the usual case where there are fixtrues under the setupfixture in our testing.

Aside from testing, I think we are agreed there is nothing more to do here.

[CharliePoole]

Do we need new images for different node types?

That would be a cool visual effect! And in addition we would use the same images in the menu so that there's a clear relationship between them! I did a quick google search if it's possible to show two icons in a tree node at all (outcome and node type)? Yes it is - it's the general approach to customize the drawing of a treeview (TreeView.DrawNode Event). With this approach you can customize any visual aspect, but you are also responsible for everything on your own. So I would have to try a few experiments to be able to better assess this. But honestly, I can well imagine that this is quite a lot of work and that's why I would postpone it for the time being.

I think there may be an easier way by just using the image list rather than going to owner-drawn. It seems to me that I have seen images that represented the type of node with some sort of an overlay to represent the outcome. I agree it can be postponed but I'll look into this possibility of composed images further when I have time.

[rowo360]

From earlier discussion, we talked about always showing the fixtures as well. So... considering only the three options, I would lean toward supporting...

• Assembly + Namespaces + Fixtures (i.e. the current NUnit tree)
• Assembly + Fixtures

I think your suggestion is a good one and it fits in perfectly with your words about the conservative introduction of new features. It reduces the combinations essential - I like it! Well, it means that the user can just show/hide the namespace part!

[rowo360]

On reconsidering, I realized that the same Fixture name can of course be used in two namespaces already. So if the user hides the namespace parts, he will already encounter now that the Fixture name is listed twice in the list. That's ok from my point of view - I'm just mentioning it and don't want to change our previous decisions.

[CharliePoole]

It's also no different from how VS or our FixtureList shows them.