Tests inherited from Generic test fixture

[CharliePoole]

In case, when TestFixture inherits from (generic) class, which contains tests,

1) the tests in inherited class and the base class are displayed separately 2) "Browse th source" for tests in base class is not available

example:

class EntityEditTests<TEntity>
{
    [Test]
    public void DeleteEntity()
   {
           ...
   }
}

[TestFixture]
class DocumentTests : EntityEditTests<Document>
{
    [Test]
    public void SignDocument
   {
           ...
   }
}

^{[jnm2—edited to add code fences so that generics weren't interpreted as HTML elements]}

Instead of showing two tests for DocumentTests, one test for DocumentTests is displayed and one test for EntityEditTests' !

See discussion at https://bugs.launchpad.net/nunit-vs-adapter/+bug/1194734

[mnivet]

I've got some tests that follow that pattern, and when running them in the CI I've got a warning message.

Transposed to the given example the message would be : No source data found for DocumentTests.DeleteEntity

This seem to be due to the GetNavigationData method of TestConverter class that is called with the name of the final class instead of the name of the implementation class of the method Or may be it's that method that should look for a base class when not found the final class ? Like done for async methods.

[CharliePoole]

We should check for an nunit bug then. Nunit should be providing the proper class name. On Dec 17, 2013 5:15 AM, "mnivet" notifications@github.com wrote:

I've got some tests that follow that pattern, and when running them in the CI I've got a warning message.

Transposed to the given example the message would be : No source data found for DocumentTests.DeleteEntity

This seem to be due to the GetNavigationData method of TestConverter class that is called with the name of the final class instead of the name of the implementation class of the method Or may be it's that method that should look for a base class when not found the final class ? Like done for async methods.

— Reply to this email directly or view it on GitHubhttps://github.com/nunit/nunit-vs-adapter/issues/6#issuecomment-30749482 .

[bradenb]

I'm using a library called SpecEasy which has you implement all tests as a generic NUnit base class. This issue isn't a big deal on my local machine, but when we build on TFS I get a "No source data found..." warning for all of my specs. I looked at the discussion on Launchpad and it looks like there's no plan to make a fix, is that accurate?

[CharliePoole]

We haven't used Launchpad for a long time. Can you point me to the discussion in question?

Right now, this is not a problem that's on our radar, but if you can give us some more info we'll look into it. As a start, what version of the adapter are you using and what do your generic classes look like?

[CharliePoole]

Sorry, I see the discussion is cited above.

@OsirisTerje This has never been categorized (labelled) or assigned any milestone. What should we do with it?

[bradenb]

Thanks for the response.

I am using the version provided through Visual Studio extensions which looks like 2.0.0.0. The library that contains the generic base class is SpecEasy. The generic base class is here: https://github.com/trackabout/speceasy/blob/master/SpecEasy/GenericSpec.cs which also inherits from https://github.com/trackabout/speceasy/blob/master/SpecEasy/Spec.cs which has the actual test attributes applied.

EDIT: Here is an example of a Spec I wrote using the library: https://gist.github.com/bradenb/2d039a083dc2a5a3a9c6

So what will end up happening is for each test, we get something like: "No source data found for Namespace.NameOfTestClassSpec.Verify"

I appreciate your time.

[CharliePoole]

Is your test running OK, aside from seeing this warning message that applies to the location of the source code?

Given that the NUnit tests are in the library and not in your code, it makes absolute sense that we can't find the source. We don't have the source! The fact that we give a warning when running under TFS might be a bug. It only makes sense under the VS IDE.

The earlier post referred to tests showing up as two separate classes. I gather that's not what is happening for you however.

[bradenb]

Yes, the tests pass just fine in both VS 2013 and TFS 2012, really I just want to be able to suppress the warnings from TFS since it makes it difficult to sort out where the real issues are with the build. I do see these messages in the Test output in VS, but not as actual warnings.

And yeah, I guess I wasn't really thinking about the differences in these situations; it would be great if I could somehow associate a method in my Spec with the test being executed or even just suppress the warnings, but I see this actually is working as intended.

Thanks

[OsirisTerje]

I'll grab @bradenb's code above and use it on a TFS instance, and get a repro, and see if I can pinpoint where this message comes from. It should be equal in VS and TFS, but the interfaces being used are not absolutely identical.

[CharliePoole]

I'm guessing it's equal in the two cases but more visible in the TFS output. Since there is no use of the source in TFS, maybe we should skip the message. Alternatively, we could create just a single warning if some classes have no source.

[cklutz]

I'm not sure if it's of no use in TFS (builds). Consider the following: you have a test failure/assertion during the build. If you now open the build report, open the tests (they get loaded into VS usually), If you then try to navigate to the test code in question, I think you need the source information.

[CharliePoole]

Maybe @osiristerje can try this (I'm traveling) and see. I think VS will give its own message if the source is not available.

In the same way, the ide gives a "source not available" message, possibly making our log message unnecessary except when debugging the adapter.

[CharliePoole]

On the surface, it seems like we would want to fix this in 2.0.

[jnm2]

I fixed this bug in the NUnit 3 adapter (two commits at the end of https://github.com/nunit/nunit3-vs-adapter/pull/454). If anyone is waiting for this fix, the test can be brought straight over. The fix will have to be translated to Mono.Cecil rather than System.Type reflection.