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.
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.
Log in to post a comment.