Re: Data-driven Tests in NUnit 2.5

"Charlie Poole" <[email protected]> Sun, 16 Mar 2008 18:08:46 -0700
Newsgroups gmane.comp.windows.dotnet.nunit.devel
Message-ID <004701c887cb$78d86ea0$6501a8c0@ferrari>
I left out one thing - a question.

If a fixture contains testcases like this...

 	 [TestCase( 1000, 10, 100.0000)]
 	 [TestCase(-1000, 10, -100.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.

Which do you prefer for this case?

Charlie


> -----Original Message-----
> From: Charlie Poole [mailto:[email protected]] 
> Sent: Sunday, March 16, 2008 6:03 PM
> To: '[email protected]'; 
> '[email protected]'
> Subject: Data-driven Tests in NUnit 2.5
> 
> Hi All,
> 
> We've had much discussion on the need for parameterized or 
> data-driven tests in 2.5. I thought I'd outline here some 
> thoughts about where I see it going.
> 
> [NOTE: This is separate from the discussion of Theories, 
> which is taking place on NUnitV3 currently. In fact, I'm 
> writing this to put down my thoughts about data-driven tests 
> before I jump into the Theories disussion.]
> 
> From all that has been said and my own research and 
> experimentation, I think there is a need for two types of 
> data-driven tests:
> 
> 1. Those whose data arguments are specified right in the 
> metadata through a custom attribute.
> 
> 2. Those whose data is provided separately - from a file, an 
> array or collection or an iterator.
> 
> For purposes of this discusssion, I'm calling the first 
> category "static" data, the second "dynamic." Bear in mind 
> it's actually all dynamic, but what I mean by "static" in 
> this context is that the actual values used are contained in 
> the metadata. For "dynamic"
> data, the metadata only contains instructions for how to get 
> the data - a method name for example.
> 
> For static data, NUnit can construct separate test cases at 
> load time for each set of arguments.
> For dynamic data, this would be possible with some changes, 
> but I'm making a design decision not to do it at this point.
> 
> That means that test cases created with static data will show 
> up in the tree of tests individually.
> Those constructed with dynamic data will not show up 
> separately, but will produce separate results when the tests 
> are run. Tests are already capable of returning multiple 
> results in NUnit but the Gui will need to be modified to display them.
> 
> Internally, NUnit will support an extension point for 
> providing data to tests. The extension will return one of two 
> things to NUnit:
> 
> 1) An actual data source, if the data is static.
> 2) An object for use at runtime to get the actual
>    data source, if the data is dynamic.
> 
> The actual interfaces involved still need to be worked out.
> 
> For static test methods, I'm thinking of supporting the 
> following natively:
> 
> [TestFixture]
> public class StaticDataSample
> {
> 	 [TestCase( 1000, 10, 100.0000)]
> 	 [TestCase(-1000, 10, -100.0000)]
> 	 [TestCase( 1000, 7, 142.85715)]
> 	 [TestCase( 1000, 0.00001, 100000000)]
> 	 [TestCase(4195835, 3145729, 1.3338196)]> 	 public void
DivisionTest(double numerator, double 
> denominator, double result)
> 	 {
> 	 	Assert.AreEqual(result, numerator / 
> denominator, 0.00001);
> 	 }
> }
> 
> If you're familiar with RowTest, you'll see that this is 
> essentially the same thing, with TestCase substituted for Row.
> In fact I took the example from Andreas and I think we can 
> incorporate his code right into NUnit.
> 
> 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.
> 
> More to come on this - your comments are welcome.
> 
> Charlie
> 



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