Recent changes to feature-requests

Compile for Visual Studio 2010

2010-12-15T16:53:20Z

We are updating our tools to work with Visual Studio 2010.
We have a large codebase of unit tests that would be very useful to run on our tools updated for VS2010.
The version we currently use is NUnit 2.2.

Please add a VS2010 solution (nunit2010.sln?) and project files, and DLLs.
I wouldn't recommend replacing the existing VS2008 files, there are likely users who haven't made the transition yet.

It has been a fairly painless migration from VS2005 to VS2010 for our game and tools (C++ and C#). We skipped VS2008 in the process as we skipped Windows Vista, straight to Windows 7.

The exceptions that are seen running from VS2010 :

System.IO.FileLoadException occurred
Message=Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.
Source=mscorlib
StackTrace:
Server stack trace:
at System.Reflection.RuntimeAssembly.GetExportedTypes(RuntimeAssembly assembly, ObjectHandleOnStack retTypes)
at System.Reflection.RuntimeAssembly.GetExportedTypes()
at NUnit.Core.AddinManager.Register(Assembly assembly)
at NUnit.Core.Addins.Register(Assembly assembly)
at NUnit.Core.Builders.TestAssemblyBuilder.Load(String path)
at NUnit.Core.Builders.TestAssemblyBuilder.Build()
at NUnit.Core.Builders.TestAssemblyBuilder.Build(String testName)
at NUnit.Core.TestSuiteBuilder.Build(String assemblyName, String testName)
at NUnit.Core.SimpleTestRunner.Load(String assemblyName, String testName)
at NUnit.Core.SimpleTestRunner.Load(String assemblyName)
at NUnit.Core.ProxyTestRunner.Load(String assemblyName)
at NUnit.Core.ProxyTestRunner.Load(String assemblyName)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at NUnit.Core.TestRunner.Load(String assemblyName)
at NUnit.Util.TestDomain.Load(String assemblyFileName, String testFixture)
at NUnit.Util.TestDomain.Load(String assemblyFileName)
at Guerrilla.ATF.Common.UnitTestRunner.MakeTestRunner(String inTestAssemblyName) in D:\dev\kz4\Code\Tools\TGuerrillaATF\TestRunner.cs:line 60
InnerException:

Let me know if I can help.
thanks,

Mark

Reloading project lacks save changes prompt

2010-03-10T17:35:44Z

Steps to cause:
1. Project -> Add Assembly...
2. Find and add a dll
3. File -> Reload Project

The added dll in step two will be gone. After making a change to the project, then trying to reload the project with the original info, the user isn't prompted to save changes to the project. This dialog should have a yes, no, and cancel option, where yes opens a save prompt for the project, then continues to reload the project; where no doesn't save the project and reloads it; where cancel acts as though the reload function wasn't called.

Windows XP Pro SP3
NUnit 2.5.3.9345

Datapoint Initialization In TestFixtureSetUp Methods

2009-12-31T01:39:21Z

Currently you can only initialize instance variables marked with either the Datapoint or Datapoints attribute at their declaration or in the class constructor. Any changes you make to these variables after that do not affect the tests. That is generally a good thing. However it would be nice to be able to initialize these variables in methods marked with the TestFixtureSetup attribute. This would allow you you to move complex initialization code out of the constructors. Moving initialization out of the constructor would be nice because then code coverage tools would not show hits from when the constructors are called for tests that are not even being run, which currently happens.

Unnecessary Test Fixture Class Construction Is Undesirable

2009-12-31T00:25:48Z

It would be nice if the only TestFixture classes that were constructed were the ones being run. I when running a single test case from a single test fixture, It is constructing other unrelated TestFixtures. This is undesirable because it makes a code coverage tool report additional hits if you have code in the constructors that is being run. Even if you recommend not putting anything in the constructor, and even if I do manage to reorganize my code to not have anything in the constructor, I still may run into another situation where it is much easier or necessary to put code in the constructor of a TestFixture class.

Parallel NUnit

2009-11-18T13:41:34Z

PNunit seems good, in principle. Its nice that it can be distributed across machines. However, for the majority scenarios, it is way to complex. ..and having the configuration in a separate xml file is sooo NUnit 1.0.

I suggest....

1] Let PNunit continue to evolve as a "distributed" parallelization implementation.

2] Create intrinsic parallel support in the core of NUnit. Following are some ideas...

Like MSBuild.exe, where you can pass in the count of nodes, allow the same to be passed to the nunit console runner. It could be a configuration on the gui runner.

Have the runner create a threadpool and launch all tests in parallel using the pool. This will cover the large amount of cases and will take advantage of these new 4-core and 6-core opteron servers! If there is any dependency between tests, then that should be defined with attributes, An attribute, such as DependOnTest, could be used to sequence where need be,

This would make it very easy to take advantage of parallelism. You should only have to configure things if they are out of the norm.

Also, why not create a set of NUnit.Common.Targets that can be Imported into a C# Unit Tests project which would provide an ExecuteTests target that depends on the Build target. So, from the command line, one could call msbuild MyNamespace.MyProject.UnitTests.csproj /t:RunTests which would build if needed and execute the tests. Better integration with MSBuild would be a big win in my opinion.

Thanks,
Gary

'AND' for the nunit gui tool

2009-11-17T19:22:57Z

Details:
We'd like a way to AND: only tests including *both* A and B categories, will run, within the nunit GUI tool.
Currently there is only exposed to cmd line nunit tool, but NOT to the GUI tool, the ability to do this
(for details, see related notes, and cmd-line version of fix, in previously closed ID # 1686479)

Is there and easy way to do this?

Thanks
Ben

Returns a default port value of 50466, when 0 is passed

2009-10-05T02:43:49Z

Class: ServerUtilityTests
Method: CanGetTcpChannelOnSpecifiedPort
Testing category: Unit testing of Util.Core component

Assertion violation when the port number is 0, returns a default port value of 50466 in that case. Is it a defect?

Overwrites existing Registry key

2009-10-05T02:42:16Z

Class: NunitRegistry
Method: TestClearRoutines
Testing Category: Unit Testing of Core.Util

When adding a key with the same name, the key is overwritten without a notice. Might not be a problem from the system level.

Missing invalid char check

2009-10-05T02:36:56Z

Class: RegistrySettingsStorage
Method(s): SaveSetting, MakeChildStorage

Description: When invalid string values such as “\0” or “.” are passed as arguments to these methods, there is no invalid-char-check before call to RegistryKey.CreateSubKey system method.

Nunit 2.5.0.9122:setup not called when test method inherited

2009-10-02T08:14:32Z

When a debugger is attached ( i.e., when I am running in Testdriven.net or NUnit GUI), I found that the Setup method wont' be called if my test method is inherited from a base method.

Here's the code, the setupCount is 0, instead of the correct result, 2.

public class SetupCallBase
{
protected int setupCount = 0;
public virtual void Init()
{
setupCount++;
}
public virtual void AssertCount()
{
}
}
[TestFixture]
public class SetupCallDerived: SetupCallBase
{
[SetUp]
public override void Init()
{
setupCount++;
base.Init();
}
[Test]
public override void AssertCount()
{
Assert.AreEqual(2, setupCount);
}
}
As far as I know NUnit 2.4 will have the above test pass.

On the other hand, the test will also pass if I don't make the AssertCount as virtual/override.