Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inherited Testcase does not open source file on double click #364

Closed
a-jaeger opened this issue Jul 19, 2017 · 6 comments
Closed

Inherited Testcase does not open source file on double click #364

a-jaeger opened this issue Jul 19, 2017 · 6 comments
Labels
closed:fixedinnewversion This has been fixed in a newer version is:bug

Comments

@a-jaeger
Copy link

I am using NUnit Adapter 3.7.0.0, Visual Studio 14.0.25431.01 Update 3 and have a Testfixture inheriting a generic abstract TestFixture. NUnit discovers and runs the tests correctly, but when double clicking (or pressing F12, or using the context menu: Open Test) on the entry in the Test Explorer, the source code file is not shown. A similar issue is described in 6 and #228, each at point 2.

The code looks like this:

namespace GeoMan.Common.Tests.Base
{
    [ExcludeFromCodeCoverage]
    [TestFixture]
    public abstract class RelationBaseTests<TRelation, TRelationType>
        where TRelation : Relation<TRelationType>, new()
        where TRelationType : RelationType, new()
    {

        protected TRelation CreateRelation()
        {
            return new TRelation();
        }

        [Test]
        public void Key_ByDefault_ReturnsNotZero()
        {
            var relation = CreateRelation();

            var key = relation.Key;

            Assert.That(key, Is.Not.Zero);
        }
    }
}

namespace GeoMan.Water.Tests.Water.dotNetBF.Modules.Org
{
    [TestFixture]
    [ExcludeFromCodeCoverage]
    public class PersonAssignmentsTests : RelationBaseTests<PersonAssignment, PersonAssignmentType>
    {
    }
}

So if ind in the Test Explorer an entry with the name "Key_ByDefault_ReturnsNotZero", but when I double click the entry, the source code is not shown as I would expect it.
I have to mention, that of course there exist other inherited TestFixtures of the base TestFixture.

@CharliePoole
Copy link
Member

Someone should debug our code to determine what we get back from the engine. This might be a framework bug rather than adapter.

@OsirisTerje
Copy link
Member

I have trouble confirming this. A corresponding example works as expected.
image

(I am using 3.8 and VS 2017 though)

@OsirisTerje OsirisTerje added the confirm We need a separate confirmation of this issue label Jul 25, 2017
@CharliePoole
Copy link
Member

OP has base and derived fixtures in different namespaces. I wonder if that makes a difference.

@OsirisTerje
Copy link
Member

This works both when the classes are in the same namespace or in different namespaces, but within the same assembly.
If the classes are in different assemblies, it doesn't work.

image

Repro can be found here: https://github.com/nunit/nunit3-vs-adapter.issues/tree/master/Issue364

Sln looks like 👍
image

The XML output from the engine/framework looks like

<test-run id='0' name='Issue364.dll' fullname='D:\repos\NUnit\nunit3-vs-adapter.issues\Issue364\Issue364\bin\Debug\net5.0\Issue364.dll' runstate='Runnable' testcasecount='2'>
   <test-suite type='Assembly' id='0-1005' name='Issue364.dll' fullname='D:/repos/NUnit/nunit3-vs-adapter.issues/Issue364/Issue364/bin/Debug/net5.0/Issue364.dll' runstate='Runnable' testcasecount='2'>
      <environment framework-version='3.13.2.0' clr-version='5.0.10' os-version='Microsoft Windows 10.0.19042' platform='Win32NT' cwd='D:\repos\NUnit\nunit3-vs-adapter.issues\Issue364\Issue364\bin\Debug\net5.0' machine-name='DESKTOP-SIATMVB' user='TerjeSandstrom' user-domain='AzureAD' culture='en-US' uiculture='en-US' os-architecture='x64' />
      <settings>
         <setting name='SynchronousEvents' value='False' />
         <setting name='InternalTraceLevel' value='Off' />
         <setting name='RandomSeed' value='1053863922' />
         <setting name='ProcessModel' value='InProcess' />
         <setting name='DomainUsage' value='Single' />
         <setting name='DefaultTestNamePattern' value='{m}{a}' />
         <setting name='WorkDirectory' value='D:\repos\NUnit\nunit3-vs-adapter.issues\Issue364\Issue364\bin\Debug\net5.0' />
         <setting name='NumberOfTestWorkers' value='28' />
      </settings>
      <properties>
         <property name='_PID' value='87324' />
         <property name='_APPDOMAIN' value='testhost' />
      </properties>
      <test-suite type='TestSuite' id='0-1006' name='Issue364' fullname='Issue364' runstate='Runnable' testcasecount='2'>
         <test-suite type='TestFixture' id='0-1007' name='DocumentTests' fullname='Issue364.DocumentTests' runstate='Runnable' testcasecount='2'>
            <test-case id='0-1002' name='DeleteEntity' fullname='Issue364.DocumentTests.DeleteEntity' methodname='DeleteEntity' classname='TestProject1.EntityEditTests' runstate='Runnable' seed='392207667' />
            <test-case id='0-1001' name='SignDocument' fullname='Issue364.DocumentTests.SignDocument' methodname='SignDocument' classname='Issue364.DocumentTests' runstate='Runnable' seed='1346508508' />
         </test-suite>
      </test-suite>
   </test-suite>
</test-run

Notice that the TestProject1 assembly is not mentioned at all, so there is no way to find the source code location for the base class.
It also looks like the fullname is wrong for the DeleteEntity method, the classname has the correct naming though.

@CharliePoole @jnm2 : Is this a problem with the engine/framework ?

@OsirisTerje OsirisTerje added is:bug and removed confirm We need a separate confirmation of this issue labels Sep 23, 2021
@CharliePoole
Copy link
Member

To my memory, it has always been OK for tests to reference other assemblies, and even inherit from classes in them. But inheriting actual test methods, setups, etc. has never been explicitly supported. When this has come up before, my suggestion to users was "don't do that." :-)

@OsirisTerje
Copy link
Member

Ok, thanks! Then this can be closed, as it works for multiple namespaces within the same assembly now.

@OsirisTerje OsirisTerje added the closed:fixedinnewversion This has been fixed in a newer version label Sep 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed:fixedinnewversion This has been fixed in a newer version is:bug
Projects
None yet
Development

No branches or pull requests

3 participants