I submitted some ideas for features to NUnit... here's what I send them:

Hello, NUnitarians... I have a feature idea (or maybe it's two, really) that I'd certainly be willing to put some effort into and that I think has great merit.

The first is simple; it's based on my observation of the common case where bugs or limitations in software are often not found because the code never deals with all the possible states of data.

This is how is works: A [Test] method is set up almost exactly as it exists now, but with one or more parameters added at the discretion of the user.  An additional attribute would be attached to each parameter.  It would specify a source of data - either a database query and connection or IList instance or really any data source - which NUnit would then use to iteratively call the method, feeding each value in for multiple, discrete tests.  Multiple parameters, of course, would mean the number of tests would be the product of the total number of items in the parameter sources.  The NUnit GUI or command-line would then report the states of each of the parameters was in when a test fails. 

Certainly there’s nothing preventing someone from implementing this themselves in an individual test, however, I think there are several good arguments for having this in (or as an add-in) to the NUnit suite:  First, it would obviously make it easy to do this kind of testing, and that’s a huge goal.  Second, it would encourage this kind of essential (IMHO) testing for components.  After all, .NET is very largely about components, whether web-service-based or otherwise.   Third, it would have an indirect impact on performance testing.  If a test method is going to be run dozens of times, it makes sense that it will be noticed if it’s running slowly.  Finally, I think this could all be integrated in the elegant design that NUnit 2.0 currently posses.  This idea should not pose and backwards-compatibility problems with NUnit tests.

This brings me to my second idea: The above is an exhaustive, deterministic test – it tests all values predictably and in a repeatable manner.  But I propose two types of non-deterministic, non-exhaustive tests as well.

First, a threaded test, which could merely be another test method-level attribute that tells NUnit to run the test method in it’s own thread.  Even parameterized methods could be run in this manner with a little finesse and Reflection.  Users could either place some shared resource in the TestFixture to test concurrency and synchronization of threading, or merely use this as a mechanism to run some test concurrently, possibly speeding up the total test time.

Second, a test runner like the first idea I described which fed values into a method, but which did so using a search algorithm to try to *find* values which break the code and to delineate which sets of values (which ‘constrains’) cause the breakage and which don’t.  Admittedly, this is a very specialized case and I don’t really expect it to be accepted into NUnit.  However, it might be worthwhile to at least investigate further, conceptually.

Well, hopefully you don’t feel I wasted your time here!  I’m not sure if I articulated my ideas effectively, so if you have any comments or questions, please mail me back: chadich@yahoo.com

Richard Lowe