Closed CharliePoole closed 5 years ago
csekamal
commented
6 years ago We really need to have the user extensions supported by NunitAdapter otherwise we have to manually configure the addins for each QA for each project which is very inconvenient.
elv1s42
commented
6 years ago Would be very useful for me too
nvborisenko
commented
5 years ago Raising this issue up. I see that nunit adapter lives in tests output folder to be used by Visual Studio (or dotnet test as well as dotnet vstest). So it's great when I want to use nunit framework in my project, and to be able to execute tests, I just install nuget packages. Nothing more, it's very easy. Now I want to execute tests and report results using some additional extension. It would be really great if I can just install this extension via nuget.
Idea is the following: everything, what is related to tests execution, can be placed at output directory. This approach is followed by VS, this is why we can easy install and execute nunit tests in VS (and dotnet tools). Now what if I put my custom extension into output folder... I'm expecting that NunitTestAdapter will use it, but unfortunately not yet.
@CharliePoole is it hard to bring extensions into TestAdapter runner? We may start from ITestEventListener extensions. What do you think?
nvborisenko
commented
5 years ago Will be resolved as soon as TestAdapter will be released under netcoreapp2.0 with reference to engine 3.10.
OsirisTerje
commented
5 years ago @nvborisenko Released today, version 3.14
@CharliePoole commented on Thu Oct 17 2013
We are trying to write an NUnit plugin for FsCheck (github.com/fsharp/fscheck). The addin works fine with the standalone test runner, although it is not shown in the addin dialog. According to this converstaion in the mailing list, this is because the addin is built with .NET 4.0:
https://groups.google.com/forum/#!topic/nunit-discuss/je0VXIsVQNQ
The addin is also written and compiled using F# (3.0).
The addin does not work with the test adapter - we've tried putting the addin and its dependencies in the addins folder where the adapter lives, as well in the folder itself. It looks like it is never loaded.
It's not clear how to go about writing an addin for NUnit that works with the standalone runner, the test adapter, the test adapter NuGet package, and Resharper.
From https://bugs.launchpad.net/nunit-vs-adapter/+bug/1193957
@CharliePoole commented on Sun Oct 27 2013
The TestAdapter initialization code does not start the AddinManager service. More work will probably be needed once we start it, but that clearly has to be done for addins to be loaded.
@john-ross commented on Tue Jan 14 2014
Would it be possible to generally change the loading of addins? It would be great to have addins loaded from dependent dll files as well - then it would only be necessary to add a reference to the relevant project in Visual Studio and not to change NUnit installations. With such a setup any NUnit client (stand alone gui client, visual studio adapter, ReSharper adapter, continuous integration system, etc.) would use the same configuration with the same NUnit addins.
@CharliePoole commented on Tue Jan 14 2014
It's not possible to do this in the context of the Visual Studio TestAdapter project, since the adapter relies on NUnit itself to load addins. This bug relates to the fact that the adapter does not properly use the existing addin facility of NUnit.
Even so, I'll comment a bit further on your idea here...
Normally, a test assembly has no reference whatsoever to addin assemblies. NUnit does allow addins to be place within the test assembly itself, but this is only to simplify the initial development of addins. They are intended to be installed in a well-known location and accessed there by all clients.
Unfortunately, that well-known location is currently relative to the install directory for NUnit, which turns out to be a bad idea in the presence of third-party runners. If we were planning another NUnit 2.6.x release, that might be a bug to fix.
However, we plan to replace NUnit addins entirely in NUnit 3.0. Most existing functionality will be provided by user-defined attributes, which is a much simpler approach than writing addins. We will most likely reserve true addins for higher level capabilities, like adding new panels to the Gui.
If you would like to discuss the nunit 3.0 direction further, I suggest posting to the nunit-discuss group.
@giggio commented on Wed May 21 2014
So this is not going to be fixed in 2.x? Any idea on the dates for NUnit 3.0?
@CharliePoole commented on Wed May 21 2014
I guess my comments were a little confusing...
I'm expecting to have an alpha release of 3.0 in the fall.
Charlie On May 21, 2014 9:19 PM, "Giovanni Bassi" notifications@github.com wrote:
@CharliePoole commented on Tue Dec 01 2015
I agree this is 3.0 only. That said, the meaning changes substantially in 3.0. We will have to decide