Hi All,
I've tried to create my own extension to ITestEventListener, not for some reason console runner doesn't pick it up.
There is very little information on how to do it so I googled most of it on StackOverflow or other issues here, e.g.https://github.com/nunit/nunit-console/issues/736
Seems to me that I did everything: put it in the separate assembly, added .addins file, added correct attribute for the class of implemented method.
So when I run it from nunit3-console it doesn't print the text from TestEventListener.
Example code is here: https://github.com/NaZaRKIN123/TestMonitor
I've never written an extension, so I was just trying your code (guided by https://docs.nunit.org/articles/nunit/extending-nunit/Event-Listeners.html and related pages). The first thing I did was to follow the suggestion in nunit/nunit-console#736 and place the addins file in the correct folder - "It would have to be located in the same directory as the copy of the engine being used by the console runner". When I did that I was able to see the extension via the --list-extensions option, but the extension did not load when I ran the tests, as the console could not create an instance of the class.
First problem was that the extension was nested inside the class Monitor I don't think we support that (at least when I removed the outer class I did not get the error about not being able to create the class).
Then I got an error regarding finding the correct version of the framework. Either, we don't support that the extensions refer to the framework (and use TestContext) or I just needed to copy the additional files to the console, but I could be wrong about this. At least when I removed all references to "NUnit" version="3.12.0" from the project and the code I was able to run the tests with the additional output.
Ps. I'm moving this issue to the console project as it is more related to the engine than the framework.
EDIT: I was initially missing a don't in the text above (marked with bold)
Expanding on @mikkelbu's comments...
I've never used a nested type for an extension. All of our distributed extensions use top-level public classes for the extension points. So, it's not surprising that it doesn't work. It could be considered a bug if there's a good reason to use a nested type, but I don't see it as very important.
No part of the engine uses a reference to the NUnit framework or any other framework. The idea is that the engine is completely independent of frameworks that run under it. Extensions are fundamentally part of the engine so they should follow the same rules. For a simple test like this, you can use Console.WriteLine().
Thanks for your answers!
The first thing I did was to follow the suggestion in #736 and place the .addins file in the correct folder
Is there a way to keep everything within my repo folder anyway? If it's not version controlled then it's useless... And unfortunately, I don't have access to the console runner folder.
BTW class nesting wasn't on purpose, fixed it.
I'm afraid that's not how engine extensions are designed - they're a "per-engine" tool rather than a "per project" one.
I'll close this issue now as I think the questions are answered - please feel free to comment further if there's more to clarify. 馃檪
@NaZaRKIN123 The usual way to do this is to have one engine per project through use of NuGet packages. If your project installs the console runner and engine as a tool through a nuget package reference, and also includes your extension as a nuget package reference, everything just works!
Sound reasonable. How should I put .addins file into the packages folder if it's generated?
So when I added packages and run the next command:
\TestMonitor\packages\NUnit.ConsoleRunner.3.11.1\tools> .\nunit3-console.exe ../../../Tests/bin/Debug/Tests.dll
I don't see the output from my extension.
What is missing?
Are you saying your extension is now a nuget package? In your original example, it was in a folder in your project. Could you just post a simplified directory structure showing where the three main things are located WRT one another?
I can only fingure out 1 and 3 from the above.
Try this as a way to understand what's needed.
Examine how the two packages are installed in your tools directory. The addins file under the console runner has some relative paths in it which will find the extension directory. The extension directory itself contains an addins file, which points to the actual assembly to be loaded.
You can do the same thing either by (1) creating a nuget package for your own extension or (2) simulating the installation of the package by simply creating the directories yourself.
If your extension is just a single assembly, you don't need an addins file in the directory that contains it. NUnitV2Driver uses one because it has some supplementary files that are referenced by it but do not get loaded by the engine. Without an addins file in the extension directory, the engine will try to use every assembly it finds, which is not a problem so long as they contain extensions or at least don't throw an exception.