Cannot open test from Test Explorer for tests in a Parameterized Test Fixture

[Marty]

If I have a class with a TestFixtureAttribute that uses the NON-Parameterless constructor, Hitting F12 or right clicking->Open Test does not navigate to the test. There is also a message saying "Source: no source available"

    //doesn't work
    [TestFixture(42)]
    public class MyTestClass
    {
        [Test]
        public void MyTest()
        {

        }
    }

    //works
    [TestFixture()]
    public class MyTestClass
    {
        [Test]
        public void MyTest()
        {

        }
    }

Version: NUnit Test Adapter Beta 2.

[Charlie Poole (charlie.poole)]

I've verified this. The "no source available" message is the key, since VS obviously can't navigate to the test if it doesn't know the name of the source file containing it. This is most likely an NUnit bug, since we provide the source info for each test to the Test Window.

[Charlie Poole (charlie.poole)]

In this case, NUnit is passing "MyTestClass<Int32>" to the DiaSession as the class name. It needs to be "MyTestClass`1"

[Simone Busoli (simone.busoli)]

Hi, I looked into this. The problem is that the class name that we give to VS in this case is xxx.MyTestClass(42). I don't think it's related to generic fixtures but I assume we have a similar problem there.

The fix is very simple, it's the same removal of trailing parenthesis wrapping the arguments values that we do for methods already, but I noticed that the tests that we have in place right now cannot cover these cases, apparently because we follow two different approaches to create the tests in the real code and in the test code (which imply a different naming).
IOW, the class in the example inside our own tests will get the name xxx.MyTestClass rather than xxx.MyTestClass(42), which is what happens in the real use case. We will probably need to change our testing approach to cover these cases.

[Charlie Poole (charlie.poole)]

You're right. The comment above related to a different problem. I'll have to repost it.

There's a whole set of problems related to the fact that VS want's actual class names in standard form, while we use different naming and can even (in the case of a test case) change the name of the test to something unrelated. We're using the current approach because of the signature of the TestStarted method: it takes a TestName, not a test. What we really need to do, rather than working further to drop parentheses, etc. is to maintain a lookup of the actual test object from the name and use that object to generate both class and method names.

I'll work on this this morning.