Re: Data-driven Tests in NUnit 2.5

On Wed, Mar 19, 2008 at 2:59 PM, Charlie Poole
<[email protected]> wrote:
> 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.

You know more than me... but from my mostly user's point of view, I
think it would be great if it were in TestAttribute.

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

I suppose.

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

So what would that do, just run the test twice would be what I would
expect. Since nobody has previously done this (since you can't now)
how is that a backwards compatibility issue?

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

So am I. I see that it is possible, but I also see that it's
semantically desirable (from my own point of view). We can just agree
to disagree on that point, of course.

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

I suppose.

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

I'm interested in/curious about what DataSource will look like.

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