Re: Data-driven Tests in NUnit 2.5

"Kelly Anderson" <[email protected]> Wed, 19 Mar 2008 11:39:28 -0600
Newsgroups gmane.comp.windows.dotnet.nunit.devel
Message-ID <[email protected]>
On Wed, Mar 19, 2008 at 8:37 AM, Charlie Poole
<[email protected]> wrote:
>  > I would assume that there will also have to be some sort of
>  > notification that the GUI can pick up...
>
>  The existing events will work but may need to carry some extra information.

Sure. That should work fine.

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

>  2) A new name for a new thing

Kind of... more like an old thing doing more in my mind.

>  3) Not breaking compatibility with old apps

I'm not sure how it would..

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

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?

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

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

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