A row provider is better than what I have to do now. I don't think
it's ideal, because you're actually writing 2 methods now, 1 for the
test, 1 for the row provider. However, even with [NonNull], we'd have
to have a factory class/method. In an ideal world, I'd like to code
this:
[RowTest]
[Row(null, new MyBar(), new MyFoo())]
public void MyTest(...) { }
However, this is a limitation of the C# compiler (or of the CLR?). In
my ideal world, I don't have to code up a separate method or class to
do this. If there's any way that can be accomplished, we ought to do
that.
If it cannot be accomplished, then having a [RowProvider], while not
ideal, sounds good.
On May 11, 3:17 am, "Andrew Stopford" <[EMAIL PROTECTED]> wrote:
> Hi Guys,
>
> I prefer the rowprovider attribute over a per method attribute and I like
> Julians idea of using arrays for this (although a moot point for Gallio).
> However, Judah do you feel rowprovider attribute that Jay and Julian are
> proposing solve your testing issue? If so we can work to those lines, if not
> then its back to the drawing board :)
>
> I'd be happy for this to go into the distribution when the approach is
> agreed. It is however beyond the scope of 2.4 and would be included in 2.4.1
> .
>
> Andy
>
> On 5/11/07, Julian Hidalgo <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hi everyone
>
> > What about this: If we define an enumeration like the following:
>
> > public enum MbUnitSpecialValue
> > {
> > Null
> > }
>
> > And then we modify the RowTestAttribute's GetRow method to change
> > every occurrence of MbUnitSpecialValue.Null for null, then we could
> > write Judah's test like this:
>
> > [RowTest]
> > [Row(MbUnitSpecialValue.Null, bar, baz, ExpectedException
> > =typeof(ArgumentNullException)]
> > [Row(foo, MbUnitSpecialValue.Null, baz, ExpectedException
> > =typeof(ArgumentNullException)]
> > [Row(foo, bar, MbUnitSpecialValue.Null, ExpectedException
> > =typeof(ArgumentNullException))]
> > public void FobnicateValidatesInput(Foo foo, Bar bar, Baz baz)
> > {
> > dar.Fobnicate(foo, bar, baz);
> > }
>
> > That would be a fast change, but it doesn't solve the more general
> > problem that we face for using attributes to the define the rows:
>
> > - We can't use anything but primitive types
> > - VB 2003 compiler can't handle the Row attribute
> > - With C# 2003 we can't use null in the attribute (it works on C# 2005
> > at least).
>
> > Using a "row provider" is the best choice IMHO. In this blopg post
>
> >http://www.hpoffice.cl/julian/archive/2007/04/17/mbunit-rowtest-in-vb...
> > I proposed something similar to Jay's first example (using arrays
> > instead of generics so it works for Fx1.1 too):
>
> > [RowProvider]
> > public IEnumerable RowsForLengthTest()
> > {
> > object[] row1 = { "M", 1 };
> > object[] row1 = { "Mb", 2, GetType(ArgumentNullException) };
> > object[][] rowArray = { row1, row2 };
> > return rowArray;
> > }
>
> > [RowTest(), Provider("RowsForLengthTest")]
> > public void LenghtTest(string someString, int length)
> > {
>
> > Assert.AreEqual(someString.Length, length);
>
> > }
>
> > I'm not that worried about the key part, because these are tests so a
> > developer (or anyone) should find very quickliy if she got's a key
> > wrong. Besides, we are already using keys for combinatorial tests for
> > example.
>
> > To be honest I found the last example (using [NonNullArgument]) a
> > little confusing and harder to read that the first solution.
>
> > Regards
> > Julián
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MbUnit.User" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/MbUnitUser?hl=en
-~----------~----~----~----~------~----~------~--~---
