Re: Data Driven Addins

Hi Kelly, 

> > So long as you both know how its going to be maintained and by whom.
> 
> For the moment, Gary has taken the lead. I'll pick it back up 
> if necessary.

Cool.
 
> > I think of Gary's extension as enabling me to run a number 
> of tests in 
> > various contexts.
> >
> > I think of yours as enabling me to run a single test with different 
> > arguments.
> >
> > Since the problem is one that is well-suited to Gary's 
> extension, it 
> > naturally works well with it. But yours works well with 
> other kinds of 
> > problems.
> 
> I'm not taking mine down until I'm convinced that there is a 
> replacement that works better without loss of functionality.

That makes sense. 

Another issue to bear in mind is that there's more to it than
the underlying implementation similarities. What I mean is...
even if it's /possible/ to solve very different sorts of
problems with a common implementation, that commonality may
not be obvious to users, who may require a different syntax
so they know what they are doing.

NUnit itself has not paid a lot of attention to this issue
in the past: everything is a TestFixture and you have to 
bend your problem to fit that construct. I'd like to start
thinking a bit more in terms of the problems to be solved,
and give the user solutions that match the problem.

Examples of what I see as different problems are:

1) I want a shorthand way to specify the same test method
with several different arguments, so I don't have to
type it many times.

2) I want to run the same test in different contexts - with
a different database, under a different culture, etc.

3) I want to be able to supply an open-ended list of 
parameters to a test and run all of them as if they 
were separate tests.

4) I want to test multiple implementations of the same
interface using a standard set of tests.

5) I want to specify general statements about how a 
method should work and provide data to test those general
statements.

6) I want to specify general statements about how a method
should work and have the framework generate data sets to
test those statements.

Add your own...

Many of the above can be solved by a data-driven implementation,
but I'm not convinced that it serves the user best to make
them all /look like/ the same thing.

Reading what I've written, I think I'll copy this back to the
list so others can comment.

Charlie

commonality may not be
> 
> -Kelly
> 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/