Re: Data-driven Tests in NUnit 2.5

Hi Kelly, 

> >  > Why not [Test(1000, 7, 142.85715)] ??? Is there a naming 
> conflict?
> >
> >  1) Test already means a lot of things in NUnit. TestCases, 
> TestSuites  
> > TestFixtures, etc. are all Tests.
> 
> Ok, but they aren't all TestAttributes, are they? 
> TestFixtureAttribute doesn't inherit from TestAttribute, 
> right? Or are you just speaking semantically here...

Yes, I always try to speak semantically. :-)

More seriously, what I mean is that because it's used in so 
many ways, "TestAttribute" may be something to get away from.
 
> >  2) A new name for a new thing
> 
> Kind of... more like an old thing doing more in my mind.

Depends on point of view I guess.
 
> >  3) Not breaking compatibility with old apps
> 
> I'm not sure how it would..

See the next item. 

Consider a method like this:
  [Test][Test] public SomeMethod() { }
It would refuse to compile. To use Test as you suggest,
we would have to allow it.
 
> >  4) Test already takes an argument: the description.
> 
> This is probably the kicker if the description argument would 
> be confused with the parameters argument, which I suppose it 
> would in the case where the test has one string parameter. We 
> don't have tests with parameters at this point in any other 
> context do we? We could (if we wanted to) differentiate between
> 
> [Test("This test does stuff!")]
> public void AnOldTest()
> {
> }
> 
> and
> 
> [Test("Kelly Anderson")]
> public void ANewTest(string name)
> {
> }
> 
> by looking at the metadata, and seeing that it has a 
> parameter. It's a bit subtle... but I think I prefer this as 
> every other attribute used inside of a TestFixture aside from 
> Test doesn't run as a test, but is rather a special case. 
> This isn't a special case like SetUp or TearDown, at least it 
> doesn't seem the same to me.

Ah - we're working from different value systems here. You're
talking about what it's possible to program. I'm talking about
what will be easiest for users.

> I'll be ok with it either way, but my opinion is that 
> overloading TestAttribute for this functionality would be 
> just fine. If you can come up with a specific instance where 
> it would break old code, I'm listening. If others have 
> opinions, I'd be interested as well. From a usability 
> standpoint, why add yet another attribute?

Because adding a new form for a new function is the easiest
thing for users to understand. Overloading can sometimes
represent the triumph of cleverness over simplicity.

> >  > >  For dynamic data, I'm thinking of supporting 
> something  > like 
> > this...
> >  > >
> >  > >  [TestFixture]
> >  > >  public class DynamicDataSample
> >  > >  {
> >  > >          [Test, DataSource( typeof(MyDataSource)]
> >  > >          public void DivisionTest(double numerator, double
> >  > > denominator,  double result)
> >  > >          {
> >  > >                 Assert.AreEqual(result, numerator /
> >  > denominator, 0.00001);
> >  > >          }
> >  > >  }
> >  > >
> >  > >  Where MyDataSource is a class provided by the user. 
> I'm  still  
> > > > working on the details of this, so please throw in  your ideas. 
> > I'd  > > like to have a typesafe interface for  data, rather than 
> > using a  > > string.
> >  >
> >  > I see where you're trying to go with the type safe thing 
>  > here. 
> > That makes some sense... but don't you still have a  > problem 
> > extracing numerator, denominator and result from  > 
> MyDataSource? That 
> > part would want to be type safe too, wouldn't it?
> >
> >  The interface can be type safe, the actual returned values 
> need to  
> > be tested for a match to the argument types dynamically. That's no  
> > big deal since large parts of NUnit already work this way.
> 
> Do you have ideas about how to do this? I've been noodling it 
> for a couple of days now, and nothing really jumps out at me 
> as a solution.

Only insofar as I already described it. Since I know that I 
know how to do it, it's not something I need to spike. I'll
put out the code when I have it.

> >  > >  More to come on this - your comments are welcome.
> >  >
> >  > I'll give some thought to a type safe way to do this... 
> do  > you 
> > have anything against using generics? Or would the fact  > 
> that they 
> > aren't supported in 1.1 keep you off that track?
> >
> >  No, generics are a graeat approach for the 2.0 version of 
> the runners.
> 
> Ok, would that help?
> 
> >  > Could the tests be written in 2.0 code to test against 1.1 code?
> >
> >  Only to test them under 2.0. That may be OK for some 
> purposes though.
> 
> Ok. I wasn't sure what the official view towards generics 
> was. I'll keep noodling, maybe something will pop into my head.

Good.

Charlie

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