2

Closed

Resharper unit test runner test tree structure

description

I've unit tests structurized in that manner:

namespace X.Y.Z
{
public class Foo
{
    public string Method1()
    {
    }
}
}

public class FooTest
{
public class Method1
{
    [Fact]
    public void do_something()
    {
    }

    [Fact]
    public void throws_some_exception()
    {
    }
}
}

When tests are arranged in this way I see namespace based tree structure in Unit Test Explorer/Session (X -> Y -> Z - that's ok) and then Method1 test fixture without BarTest name before in the tree. The problem starts when I've two classes in the same namespace with methods with the same names f.ex. Class1.Method1 and Class2.Method1. Then, on the runner list I see two test fixtures named Method1. It's not clear which one is for Class1 and which for Class2 (see attachment). I can add additional nested classes but it doesn't help.
  • Unit Test Explorer/Session is set to show by Structure and Namespace

file attachments

Closed Aug 2, 2012 at 2:00 PM by mattellis
Fixed in xunitcontrib-resharper.0.6.1

comments

mattellis wrote Feb 21, 2012 at 6:37 PM

I'm not sure I follow this. Am I right in saying you have two classes, FooTest and BarTest, both living in namespace X.Y.Z? And that in both of these classes, you have a nested class called Method1, which then contains test methods? If I set up a project like that, I get the image I see in the screenshot, which is a tree view with a root node of X.Y.Z, two method nodes of Method1 and then test nodes.

In other words, the test explorer is showing the nested class name, but not the name of the owning class, so it's impossible to tell them apart. Is this right?

Interestingly, it's how the nunit plugin works...

jdubrownik wrote Feb 21, 2012 at 7:24 PM

Ypou are right. There is no name of owning class. In that case it is impossible to structurize tests like that:

Class per main tested object then nested class per each method then "facts" inside nested class per each tested execution path/scenario of method. If I do it this way I get more readable and maintainable test structure:

(class) (nested class) (method)
ListTest -> Add -> adds_item_to_list
                   -> throws_exception
                   -> do_something_else
instead of:

(class) (method)
ListTest -> Add_Adds_Item_To_List
        -> Add_Thorws_Exception

mattellis wrote Aug 2, 2012 at 1:33 PM

Fixed in changeset 6bffdf2f3d08