Re: Data-driven Tests in NUnit 2.5

Hi Kelly, 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of Kelly Anderson
> Sent: Friday, March 21, 2008 9:31 AM
> To: [email protected]; [email protected]
> Subject: Re: [nunit-developer] Data-driven Tests in NUnit 2.5
> 
> On Sun, Mar 16, 2008 at 7:02 PM, Charlie Poole 
> <[email protected]> wrote:
> > 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.
> >  <snip>
> >  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);
> >          }
> >  }
> 
> I was trying to get my mind around the issue of data-driven 
> and Theory testing, and I ran across this little tidbit in 
> the C# spec about what types could be parameters to Attributes.
> 
> C# Language Specification
> 17.1.3 Attribute parameter types
> 
> The types of positional and named parameters for an attribute 
> class are limited to the attribute parameter types, which are:
> 
>     * One of the following types: bool, byte, char, double, 
> float, int, long, short, string.
>     * The type object.
>     * The type System.Type.
>     * An enum type, provided it has public accessibility and 
> the types in which it is nested (if any) also have public 
> accessibility (Section 17.2).
>     * Single-dimensional arrays of the above types.
> 
> What this seems to mean is that for the TestCase Attribute, 
> all of the parameters have to be primitives, or type unsafe 
> object's... It limits the flexibility of how we can approach 
> this problem.
> 
> I'm still trying to come up with something that will produce 
> a compile time error/warning, but nothing comes to mind yet.

Yes, that's why my hypothetical attribute takes a type. NUnit
would have to check that the provided type actually implements
the necessary interface.

It's awkward, but not a show-stopper.

Charlie
 
> -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/
> _______________________________________________
> nunit-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-developer
> 



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