Re: Recent 2.5 Changes

Hi Olof, 

> > As usual, this is for those who track the CVS source. The rest will 
> > have to wait for alpha-4, but it shouldn't be too long...
> >
> > 1. Classes can have multiple setup, teardown, fixture setup 
> or fixture 
> > teardown methods. Base setups are run before the derived setup and 
> > teardowns are run in reverse. Within the same class 
> declaration, order 
> > is undefined, so it's not too useful but still possible.
> 
> Is there a specific reason why multiple setups/teardowns per 
> fixture is at all allowed? I would prefer 
> one-setup-per-fixture instead of undefined behaviour.

1. Some folks have asked for it so as to segregate unrelated
   setups in different methods - even in different files in
   the case of partial classes. In such cases, undefined
   order is not a problem.

2. It's consistent with NUnit moving away from a philosophy of
   "we won't give you anything you could hurt yourself with" to
   "it's up to you what you do with the tool."

3. It simplifies the code if I don't have to check this.

> >
> > NOTE: If you /override/ a base class method, you don't have two 
> > methods any more, so only the override runs. Do that if that's what 
> > you want, otherwise don't. :-)
> >
> > 2. DataSourceAttribute provides a way to point to data for 
> individual 
> > arguments just as FactoriesAttribute (I still don't like that name) 
> > points to entire test cases.
> 
> Could you provide a very brief syntax example of this?
>

[DataSource("MyData")]

FWIW, I find inline data much more conducive to doing TDD. However,
there can be a need to share data across multiple tests.

Charlie
 
> >
> > 3. TestFixtures can now have parameters, which are used in 
> searching 
> > for a constructor. You repeat [TestFixture(...)] just as you do for 
> > [TestCase(...)] and each individualized fixture is created 
> separately 
> > in the tree.
> 
> Cool! So if I have several classes implementing an interface 
> that should adhere to specific rules specified by tests, I 
> could parameterize the fixture containing those tests with 
> the specific class implementations? Great!
> 
> >
> > 4. We already had generic fixtures and now they can have parameters 
> > too. You can specify what types to use in creating a specific class 
> > from the generic declaration in three ways...
> 
> I have no clue what you are talking about, but I guess it's great ;)
> 
> >
> >  1) By preceding the constructor args with a set of
> >    Types to be used. This won't work if the first
> >    constructor arg is a Type, of course.
> >
> >  2) By using the TypeArgs named property of TestFixtureAttribute
> >
> >  3) By using a constructor that makes use of all the
> >    Type parameters - in that case NUnit will figure
> >    it out.
> >
> > I'm aware that the last bit particuarly needs documentation.
> > Consider the above as hints for the brave among you.
> >
> > Charlie
> >
> >
> >
> >
> >
> > 
> ----------------------------------------------------------------------
> > --- This SF.Net email is sponsored by the Moblin Your Move 
> Developer's 
> > challenge Build the coolest Linux based applications with 
> Moblin SDK & 
> > win great prizes Grand prize is a trip for two to an Open 
> Source event 
> > anywhere in the world 
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > nunit-developer mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/nunit-developer
> >
> 




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/