Re: Status of Data Driven tests

"Olof Bjarnason" <[email protected]> Tue, 25 Mar 2008 23:11:54 +0100
Newsgroups gmane.comp.windows.dotnet.nunit.devel
Message-ID <[email protected]>
2008/3/25, Andreas Schlapsi <[email protected]>:
>
> Hi Charlie,
>
>
> > I'm resending this, since it didn't seem to be accepted the first time.
> >
> > Hi All,
> >
> > I have a basic skeleton for static test data applied
> > to methods in the manner of RowTest.
> >
> > These work...
> >
> > [TestCase(2, 2, 4)]
> > public void TestMethod(int a, int b, int sum)
> > {
> >    Assert.AreEqual( sum, a + b );
> > }
> >
> > [TestCase(2, 2, 4)]
> > [TestCase(10, 1, 11)]
> > [TestCase(2, -2, 0)]
> > public void TestMethod(int a, int b, int sum)
> > {
> >    Assert.AreEqual( sum, a + b );
> > }
> >
> > In the first example, the test is shown right under the fixture.
> > In the second, a group is created, with the tests under it
> > just as in RowTest.
> >
> > A few differences in my implementation...
> > * Mismatched args are non-runnable rather than throwing
> > an exception at runtime.
> > * It works on static methods as well as instance methods
> >
> > I haven't yet implemented ExpectedException, TestName
> > or Description, but they seem straightforward enough.
> > Do we need/want all these?
> >
>
> Well, TestName was actually a feature request from a user of the RowTest
> extension. I think that ExpectedException makes sense. Without it, it's
> hard to verify that invalid input specified in the TestCase attribute
> should cause an exception to be thrown.
>
>
> > I'll add use of a property or method to return argument
> > lists in the fashion of IterativeTest.
> >
> > I'm considering allowing methods with return values, with
> > the test cases specifying the expected value and NUnit
> > doing an automatic assertion on equality.
> >
> > [TestCase(2, 2, Expect=4)]
> > [TestCase(10, 1, Expect=11)]
> > [TestCase(2, -2, Expect=0)]
> > public int TestMethod()
> > {
> >     return MyAddMethod(a, b);
> > }
> >


Lovely syntax! Thumbs up!

> This would allow something very close to testing
> > the production code directly. Does it look like
> > it might be useful?
> >
>
> Nice idea. It makes the expected result distinguishable from the input.
>
>
> Andreas
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>
> _______________________________________________
> nunit-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-developer
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

_______________________________________________
nunit-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nunit-developer