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