Re: Data Driven Addins

Hi Gary,


> > I think for NUnit 2.4 and 2.5 IterativeTest (or a property 
> > data source) should require the method or property providing 
> > the data to be static.
> 
> That would sure make it easy.
> 
> Charlie
> 

 
Hiya! Obviously, I'd be a bit disappointed with that, but I am being biased
again for the single very isolated case I have with the interaction between
parameterized fixtures and paramterized tests!
 
Well, Andreas was talking about IterativeTest, which works without having a
fixture instance.
 
Your extension (leaving out the idea that you are trying to combine them)
would have a 
fixture instance, upon which methods could be defined.
 
I suppose I could still do what I'm doing now without using the new
extension point, but I'm trying to envisage how any new extension points
will look in general, there is a good chance that I'm missing an obvious
point ;-)
 
We currently have a TestCaseBuilder extension point, where BuildFrom returns
a TestCase. Different extensions may want to create paramterized tests for
RowTest (a la MBUnit), DataSource (a la VSTS), ParameterizedTest (as we've
discussed recently), but they all have similar behaviour.
 
Note that TestCaseBuilder currently returns a Test, even though the name
hasn't changed. In fact, that's how you are able to return a TestSuite from
it.
  
Our extensions currently have to create container classes around the method
to be invoked, holiding the paramters to invoke it with. That's one piece of
common functionality - our extensions should be able to create a common
ParameterizedTestMethod, and set the expected exception etc. 
 
Yes 
 
Actually obtaining the parameters seems to be a secondary task (there's less
commanality - the parameters are either given by attributes decorating the
method, or by a separate IEnumerable method, or potentially in the future by
a further extension point - whether Theory/ or Pex)
  
Yes. Ideally - I think I wrote this somewhere else -
ParameterizedTestExtension should have its own extension point for providing
the data. But I don't want to do that till we implement mono.addins in 3.0,
since that was one of the main reasons for selecting mono.addins. Our
discussion here has been (for me) about how much of this it is practical to
do in the old paradigm, where NUnit has extensions but extensions don't have
extensions. I'm still not sure, but it seems as if we could create an
extension point for getting data IFF we required the test builders
themselves to look for it and invoke it. I'm not sure how this would work -
just thinking out loud.


Charlie
 
 Cheers,
Gary
 


  _____  

Everything in one place. All new Windows Live!
<http://www.windowslive.co.uk/get-live>

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