Re: Data-driven Tests in NUnit 2.5
"Charlie Poole" <[email protected]> Mon, 17 Mar 2008 14:05:00 -0700
| Newsgroups | gmane.comp.windows.dotnet.nunit.devel |
|---|---|
| Message-ID | <006901c88872$921ca820$6501a8c0@ferrari> |
Hi Gary,
I wondered what the reasoning behind this is - my addin that works with
NUnit 2.4.6 populates the tree for both static and dynamic data.
It wouldn't be generally possible or desirable to do this. So there needs to
be room for both approaches.
> 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.
>
It looks good - my addin just uses a string but it isn't that great that
it's just a string reference. You haven't said what contract your data
source object will have - will it implement a specific interface, or
decorate a method?
Still early stages - could be either - I'll publish something as soon as I
have done some
experiments. I lean toward an interface.
Also, what interface will the method/property you call have - I have my
addin call a property that returns IList<ParameterizedTestData>, but Kelly's
original suggestion was to have an IEnumerable property.
Either of those would work for the data. We also need an interface that
returns the object with the
data interface - analogous to IEnumerable / IEnumerator.
It all looks good though!
Oh, when you say that you may have NUnit implement TestCase natively - will
there still be a way for us to use the same underlying mechanism (i.e. we
may want a different syntax on top for some reason, maybe for creating a
MBUnit addin?)
Yes. The NUnit implementation will function like an addin in all ways
except that NUnit won't have
to go out and find it. That's actually how NUnitTestCaseBuilder and friends
work now. By doing it
this way, we're always exercising the same interface that extensions use -
fewer surprises that way.
Charlie
>
> I left out one thing - a question.
>
> If a fixture contains testcases like this...
>
> [TestCase( 1000, 10, 100.0000)]
> [TestCase(-1000, 10, -0.0000)]
> [TestCase( 1000, 7, 142.85715)]
> [TestCase( 1000, 0.00001, 100000000)]
> [TestCase(4195835, 3145729, 1.3338196)]
>
> ... it would be possible to have the five test
> cases in the tree directly under the fixture or
> to group them in a further level named for the
> method as RowTest does.
>
I prefer the second, that's what I've got in my addin, and (a poor attempt
at drawing) my tree looks like
|-DivisionTest
|-|-Case1
|-|-Case2
but I force the user to specify the names of the test cases
[InlineData("Case1", new object[] { 1000, 10, 100.0000 })]
[InlineData("Case2", new object[] {-1000, 10, -0.0000 })]
public void DivisionTest(...
I don't know whether anyone finds this useful or not?
Cheers,
Gary
_____
Messenger on the move. Text MSN to
<http://mobile.uk.msn.com/pc/messenger.aspx> 63463 now!
-------------------------------------------------------------------------
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