Re: Modificatons to NUnit 2.5 Data-Driven tests

If the test cases are being created as the test is loaded,
and - for example - displayed in the gui, then it doesn't seem
possible to use the same instance for execution unless we
use that instance for every execution of the test. Failure
to destroy instances properly at the end of each run was a source
of bugs in the past, so now we clean up properly.

To be honest, I don't really see why this type of test factory -
one that creates a test at load time - should ever need to be an
instance member of the fixture. Most of my own use for a test 
factory would be to allow reuse of parameters, which would 
otherwise be expressed as metadata, and static works perfectly 
well in that case, since the values are constant.

Maybe I shouldn't allow use of instance members until/unless 
the need for it makes sense to me. :-)

Charlie


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of Jeff Brown
> Sent: Saturday, May 31, 2008 12:35 PM
> To: [email protected]
> Subject: Re: [nunit-developer] Modificatons to NUnit 2.5 
> Data-Driven tests
> 
> It seems kind of pointless to me to have an instance for 
> evaluating data sources if it's not the one being used to 
> execute the tests.
> 
> Jeff.
> 
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On 
> Behalf Of Charlie Poole
> Sent: Saturday, May 31, 2008 2:10 AM
> To: [email protected]
> Subject: [nunit-developer] Modificatons to NUnit 2.5 Data-Driven tests
> 
> Hi All,
> 
> Kelly has pointed out several issues with 
> DataSourceAttribute, all of which revolve around the fact 
> that the property runs at load time, which is before the 
> tests are ever executed. This leads to some potential user 
> confusion, which is not helped by the fact that the attribute 
> name /sounds like/ data that is input to a test, rather than 
> a set of parameters used to construct the test.
> 
> MbUnit has a long history of using "Factory" in the names of 
> attributes that create tests. This may be a better naming 
> convention, even though they seem to have had one or two 
> users confused by the issue as well.
> I'm inclined to using it for us as well.
> 
> I also think now that limiting the data source (or factory) 
> to be a static property is too limiting. We should allow 
> properties, methods or fields and let them be either static 
> or instance. Users will just need to be aware that the 
> instance creating the test cases is not necessarily the same 
> as the instance that executes them.
> 
> That's the general way I'm looking at modifying this stuff. 
> Any thoughts?
> 
> Charlie
> * Factory attribute on the property or method providing test cases
> * 
> 
> 
> 
> 
> --------------------------------------------------------------
> -----------
> 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/
> _______________________________________________
> nunit-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-developer
> 
> 
> --------------------------------------------------------------
> -----------
> 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/
> _______________________________________________
> nunit-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-developer
> 



-------------------------------------------------------------------------
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/