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

Bug #1065254 reported by Marty
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
NUnit Test Adapter
Fix Released
High
Charlie Poole

Bug Description

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.

tags: added: vs-adapter
description: updated
affects: nunitv2 → nunit-vs-adapter
tags: removed: vs-adapter
Revision history for this message
Charlie Poole (charlie.poole) wrote :

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.

Changed in nunit-vs-adapter:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Charlie Poole (charlie.poole) wrote :

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

Changed in nunit-vs-adapter:
assignee: nobody → Charlie Poole (charlie.poole)
milestone: none → 0.93
Revision history for this message
Simone Busoli (simone.busoli) wrote :

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.

Changed in nunit-vs-adapter:
status: Triaged → Confirmed
Revision history for this message
Charlie Poole (charlie.poole) wrote :

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.

Changed in nunit-vs-adapter:
status: Confirmed → Triaged
status: Triaged → In Progress
importance: Medium → High
Changed in nunit-vs-adapter:
status: In Progress → Fix Committed
Changed in nunit-vs-adapter:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.