Side By Side Versions of NUnit (e.g. 2.4.0 & 2.4.7)

Topics: Developer Forum
Jul 13, 2008 at 3:37 AM
How would one get this code to compile and work with more recent versions of NUnit (e.g. 2.4.7)?

I tried mucking around with the source code by changing references to the newer DLLs, but I must be missing something... everything I tried ends up having no effect and the NUnit tests do not show up in the Tests View in VS.

It would be good if there was only one way to "install" this nunit support instead of having bat files and a setup project.  It is confusing as to which one should actually be used.  For instance, it appears that the setup proj will not install the NUnitTemplate.zip file, and you have to use the deploy.bat file to do that.  Also, it would be great to not have to "include" RegPkg.exe in the source code and setup, especially since it was not documented (at least that I saw) where it came from.

Thanks!
Coordinator
Jul 13, 2008 at 11:13 AM
Edited Jul 13, 2008 at 11:15 AM
Sorry, I have forgot to check in files with a new license. Todays Changeset includes changed files and a new setup that installs templates.

regpkg.exe is part of Visual Studio 2008 SDK. It is said in documentation that it should be used to register unit tests with Visual Studio.

there is only one way to install. using setup. deploy.bat is only for development.
Jul 20, 2008 at 7:40 PM
The version of nunit you seemed to have developed NUnitForVS against appears to be 2.3.6293.0.  However, trying to change the assemblies references over to 2.4.7 nunit dlls (and fixing a class name change, and one property reference) results in no tests showing up.  I think there is something quite a bit different about later versions of nunit (e.g. 2.4.7) that prevent NUnitForVS when compiled against it from working.  Please let me know if you can get NUnitForVS to work against nunit version 2.4.7 or later, and of course, post the changes to the code you'd have to make!

Thanks!
Coordinator
Jul 20, 2008 at 9:49 PM
Edited Jul 20, 2008 at 9:51 PM
NUnitForVS don't uses NUnit to run the tests. Only to find them. You don't get any advantages from new version of NUnit.
Aug 8, 2008 at 9:59 PM
Hi nesher, I don't quite understand. You said "NUnitForVS don't uses NUnit to run the tests", then who does?

Here's the issue I got:

I have a large test project with 1677 tests, which is against NUnit 2.4.8 dlls. After installing NUnitForVS (using 2.3), opening the project and then runing testing, I can see the tests in test view and it shows there are 944 tests with 276 failed, but in fact all 1677 tests are all passed in NUit (2.4.8). For all the failed tests in test view, the exception is "wrong signature". Obviously, this is caused by the out of date NUnit dlls that NUnitTest.dll is calling. I also run the tests with TestMatrix addin (previously TestRunner), its result is the same as NUnit (2.4.8).

Any idea?
Coordinator
Aug 8, 2008 at 11:58 PM
Could you please give me exact exception message you get?
Aug 11, 2008 at 8:52 PM
Edited Aug 11, 2008 at 8:55 PM
UnitTests project in CruiseControl.NET-1.4.0.3524 source code (http://sourceforge.net/project/showfiles.php?group_id=71179&package_id=83198)  is a good example to test NUnitForVS. After you get NUnitForVS installed, open CruiseControl.NET solution in VS and compile UnitTests project and then run tests. At the same time you can open compiled ThoughtWorks.CruiseControl.UnitTests.dll and run tests with NUnit (2.4.8) to compare the test result to what NUnitForVS gets.

The exceptions I got from NUnitForVS are like the folowings. 
"NUnitTestAdapter throws exception: System.Exception, Method has wrong signature: ThoughtWorks.CruiseControl.UnitTests.Core.ArgumentParserTest, RemoveListener"
"NUnitTestAdapter throws exception: System.Exception, Method has wrong signature: ThoughtWorks.CruiseControl.UnitTests.Core.Sourcecontrol.CvsTest, VerifyAll"
"NUnitTestAdapter throws exception: System.Exception, Method has wrong signature: ThoughtWorks.CruiseControl.UnitTests.Core.IntegrationResultTest, CreateIntegrationResult"
.......

Hope it's helpful.

Thanks,
Coordinator
Aug 12, 2008 at 5:55 AM
What signature have this Methods?
Aug 12, 2008 at 2:49 PM
Actually, I don't see anything wrong with the signatures of these methods. It would be better if you could dig into the project yourself as I described above. I have a feeling that the exception is related to the version of nunit.*.dll.
Coordinator
Aug 12, 2008 at 8:53 PM
I has nothing to do with with nunit version. As I said nunit is being dynamicaly loaded from GAC.
Exception that you mentioning is being thrown during type (with TestFixtureAttribute) validation. If Setup, Teardown, TestFixtureSetup or TestFixtureTeardown having wrong signature.
They must be public, non static, return type void, and have no parameters.
Aug 12, 2008 at 10:14 PM
OK then, maybe you're right and this addin has nothing to do with nunit. I am not familiar with the architecture of VS's addins. what I know is your addin works inproperly. As I described above, for CruiseControl.NET-1.4.0.3524 there supposed to be 1677 tests, but NunitForVS reported only 944 tests. Something must be wrong somewhere. Why can't you simply take a look at the project when you get a chance?

NunitForVS is a good solution for integrating NUnit into VS, I just hope it can be perfect.
Coordinator
Aug 13, 2008 at 8:23 AM
Edited Aug 13, 2008 at 8:29 AM
Tests you where mentioning having protected Setup and Teardown methods. I would actually say that NUnit has error if it allows such methods.
Visual Studio unit tests are also requiring setup and teardown methods to be public.

Aug 13, 2008 at 3:47 PM
I'm sorry if I didn't make my expression clear enough. Let's put the exception aside and take a look at the different test results. With either NUnit.exe (v2.4.8), TestMatrix(v2.0) addin or ReSharp addin(v4.0), all 1677 tests can be found and tested correctly. However, NUnitForVS can only get 944 tests. Does that sound strange? I don't know why. But I'm sure something must be wrong with NUnitForVS.
Coordinator
Aug 15, 2008 at 9:44 PM
You had right. There was a bug. Thanks :)
Bug is fixed in change-set 36088.