Yes and no. :-)
I don't like the no answer. To create an extension we would need to create
a new test fixture attribute too. I think that is unnecessary.
So the yes answer would be first I will make it so that extensions of this
nature do not require a new test fixture attribute. After that has been
applied we can do this as a pure extension. I think that this is belongs in
the core distribution as it will be useful to many people.
I make the changes to allow for extending in this way last night. I have
not committed them yet. We will have to run it by Andy first.
On 5/10/07, Judah Himango <[EMAIL PROTECTED]> wrote:
>
>
> I like that.
>
> I agree that having multiple classes is too laborious and less clear.
> I like your solution.
>
> For something like this, can we extend MbUnit to do this? Or do we
> have to code something up inside the MbUnit source to make this work?
>
> On May 9, 9:34 pm, "Jay Flowers" <[EMAIL PROTECTED]> wrote:
> > Hmm,
> >
> > How about:
> >
> > [TestFixture]
> > public class MyTest
> > {
> >
> > [NonNullArgument]
> > public Foo FooProvider()
> > {
> > return new Foo();
> >
> > }
> >
> > [NonNullArgument]
> > public Bar BarProvider()
> > {
> > return new Bar();
> >
> > }
> >
> > [NonNullArgument]
> > public Baz BazProvider()
> > {
> > return new Baz();
> >
> > }
> >
> > [NullArgumentTest()]
> > public void MyTest(Foo foo, Bar bar, Baz baz)
> > {
> > dar.Fobnicate(foo, bar, baz);
> >
> > }
> > }
> >
> > I am trying to keep the solution to one class. It feels like to much
> work
> > to have to write multiple classes for these types of things.
> >
> > My intention is to have the method decorated with the NullArgumentTest
> > attribute tied to other methods decorated with the NonNullArgument
> > attribute. The parameters defined on the NullArgumentTest method must
> match
> > the return types of the NonNullArgument methods. This way is not string
> > based, yet it still is not enforced by the compiler. The runner for the
> > NullArgumentTest would be similar to the Combinatorial test runner. It
> > would be responsible for executing all the combinations, testing each
> > argument with null.
> >
> > Thoughts?
> >
> > On 5/9/07, Judah Himango <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> >
> > > Hi Jay, thanks for the reply.
> >
> > > Real quick, I am a newbie with MbUnit, so bear in mind I don't yet
> > > know how to extend MbUnit to support this, if that's what you're
> > > saying we should do.
> >
> > > Regarding your suggestion, I think that would be an improvement. I
> > > agree that the "ThisIsAKey" thing isn't too attractive.
> > > UsingFactoriesAttribute has a string key like that, but I understand
> > > the key there is the method name. Either way, it's not very
> > > attractive, although better than the current situation.
> >
> > > Perhaps we can do better. Here's what I'd like to write:
> >
> > > [Test]
> > > public void MyTest([NonNull] Foo foo, [NonNull] Bar bar, [NonNull] Baz
> > > baz)
> > > {
> > > dar.Fobnicate(foo, bar, baz);
> > > }
> >
> > > Then have MbUnit supply null and verify it throws an
> > > ArgumentNullException. That's ideal, however, I realize the unit test
> > > framework won't know how to supply non-null foo instances to test the
> > > other parameters, e.g. supply values of { someFoo, null, baz }. In
> > > order for that to work, it would seem MbUnit needs to know how to
> > > create Foo instances. As I understand it, you guys accomplish that
> > > using factories. So the unit test might look something like this:
> >
> > > [Test]
> > > public void MyTest([NonNull(typeof(FooFactory))] Foo foo,
> > > [NonNull(typeof(BarFactory))] Bar bar, [NonNull(typeof(BazFactory))]
> > > Baz baz)
> > > {
> > > dar.Fobnicate(foo, bar, baz);
> > > }
> >
> > > That's a bit laborious as well. Perhaps if we did a one-time setting
> > > of these factories:
> >
> > > [Setup]
> > > public void Setup()
> > > {
> > > MbUnit.Factories.Add(typeof(FooFactory));
> > > MbUnit.Factories.Add(typeof(BarFactory));
> > > MbUnit.Factories.Add(typeof(BazFactory));
> > > }
> >
> > > public void MyTest([NonNull] Foo foo, [NonNull] Bar bar, [NonNull] Baz
> > > baz)
> > > {
> > > dar.Fobnicate(foo, bar, baz);
> > > }
> >
> > > That's a bit cleaner and more readable and we've accomplished the
> > > ideal syntax by doing one-time factory additions to the setup.
> >
> > > For validation other than null checking, one could add a [InRange(min,
> > > max)] attribute for ArgumentOutOfRange validation, a [NonEmptyString]
> > > attribute, and so on. What do you think, Jay?
> >
> > > On May 8, 8:11 pm, "Jay Flowers" <[EMAIL PROTECTED]> wrote:
> > > > Judah,
> > > > I don't see a way that I particularly like. How about we make a new
> > > way?
> >
> > > > [TestFixture]
> > > > public class ExampleTest
> > > > {
> >
> > > > [ParameterProvider("ThisIsAKey")]
> > > > public Parameters[] MyParameters()
> > > > {
> > > > List<Parameters> ParametersList = new List<Parameters>();
> >
> > > > ParametersList.Add(typeof(ArgumentNullException), null, bar, baz)
> > > > ParametersList.Add(typeof(ArgumentNullException), foo, null, baz)
> > > > ParametersList.Add(typeof(ArgumentNullException), foo, bar, null)
> >
> > > > return ParametersList.ToArray();
> >
> > > > }
> >
> > > > [ParameterizedTest("ThisIsAKey")]
> > > > public void MyTest(Foo foo, Bar bar, Baz baz)
> > > > dar.Fobnicate(foo, bar, baz);
> >
> > > > }
> >
> > > > I am not very happy with the key part. What do you think?
> >
> > > > Smiles,
> > > > Jay
> >
> > > > On 5/8/07, Judah Himango <[EMAIL PROTECTED]> wrote:
> >
> > > > > I want to test that my method throws argument exception on bad
> input.
> >
> > > > > // Here's the method signature:
> > > > > public void Fobnicate(Foo foo, Bar bar, Baz baz) { ... }
> >
> > > > > // Validate Foo
> > > > > [Test, ExpectedException(typeof(ArgumentNullException))]
> > > > > public void FobnicateThrowsOnNullFoo()
> > > > > {
> > > > > dar.Fobnicate(null, bar, baz);
> > > > > }
> >
> > > > > // Validate Bar
> > > > > [Test, ExpectedException(typeof(ArgumentNullException))]
> > > > > public void FobnicateThrowsOnNullBar()
> > > > > {
> > > > > dar.Fobnicate(foo, null, baz);
> > > > > }
> >
> > > > > // Validate Baz
> > > > > [Test, ExpectedException(typeof(ArgumentNullException))]
> > > > > public void FobnicateThrowsOnNullFoo()
> > > > > {
> > > > > dar.Fobnicate(foo, bar, null);
> > > > > }
> >
> > > > > Needless to say, that's pretty laborious just to test input. I
> spotted
> > > > > MbUnit's [RowTest] attribute, and thought that would help. Then
> the
> > > > > unit tests could become just 1 test:
> >
> > > > > [RowTest]
> > > > > [Row(null, bar, baz, ExpectedException =
> > > > > typeof(ArgumentNullException)]
> > > > > [Row(foo, null, baz, ExpectedException =
> > > > > typeof(ArgumentNullException)]
> > > > > [Row(foo, bar, null, ExpectedException =
> > > > > typeof(ArgumentNullException))]
> > > > > public void FobnicateValidatesInput(Foo foo, Bar bar, Baz baz)
> > > > > {
> > > > > dar.Fobnicate(foo, bar, baz);
> > > > > }
> >
> > > > > That would be brilliant, but it doesn't work because the C#
> compiler
> > > > > must know attribute values at compile time. :-(
> >
> > > > > Is there an elegant way to validate several arguments like this
> using
> > > > > MbUnit?
> >
> > > > --
> > > > Jay Flowers
> > > >
> ----------------------------------------------------------------------
> > >http://jayflowers.com
> > > >
> ---------------------------------------------------------------------
> >
> > --
> > Jay Flowers
> > ----------------------------------------------------------------------
> http://jayflowers.com
> > ---------------------------------------------------------------------
>
>
> >
>
--
Jay Flowers
----------------------------------------------------------------------
http://jayflowers.com
---------------------------------------------------------------------
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
