Thanks, Jeff.
Sounds promising.
I did not get from your response whether generic test methods are
possible.
If so, can the generic type parameters be yielded at run-time by some
factory method, just as with the generic fixture parameters?
Thanks.
On 10/08/2009, at 13:18, Jeff Brown wrote:
>
> Wow that's a pretty complicated case!
>
> There are a few things in MbUnit v3 that might help you:
>
> 1. You can specify data sources for generic fixture type parameters
> and
> generic test method type parameters.
>
> eg. Using Column but any other data source will do, including a
> [Factory] if
> you like. (Just make sure the factory method yields Type objects.)
>
> [Test]
> public void MyTest<[Column(typeof(Abc), typeof(Def))] T>() { ... }
>
>
> 2. Given just how dynamic this case is, you might consider using a
> [DynamicTestFactory].
> (http://www.gallio.org/api/html/
> T_MbUnit_Framework_DynamicTestFactoryAttribu
> te.htm)
>
> The API documentation includes an example of a dynamic test factory
> that is
> also data driven. So what you could do is to use a data driven
> dynamic test
> factory to produce a list of test cases for each combination of
> inputs.
>
> Since you can run arbitrary code within the factory it should be
> pretty easy
> to handle the dynamically generated entity tag types used by the
> test cases.
>
> Jeff.
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On
> Behalf Of Mark Kharitonov
> Sent: Sunday, August 09, 2009 11:08 PM
> To: MbUnit.User
> Subject: MbUnit Generic test method for dynamically generated types.
>
>
> Hello.
> I have a somewhat advanced question.
>
> Our unit tests are currently written in mstest, however, one
> has to go
> extra mile to simulate combinatorial tests there. So, I am
> examining the
> option of migrating to MbUnit.
> In our tests, I simulate combinatorial tests using in-memory data
> provider, custom attributes on the methods and populate the data
> provider
> from the ClassInitialize method. All of these are easily done in
> MbUnit.
> There is, however, an additional twist to our setup - dynamically
> generated
> types.
> The thing is that a test method input determines the features
> of the
> tested dummy entity and a new dummy entity type may have to be
> produced to
> support these features. The new type is produced by generating a
> unique tag
> type corresponding to the feature spec. This tag type is then used
> as the
> generic type parameter of the DummyEntity<T> type.
> So, each cartesian multiplication product corresponds to some
> combination of features to be tested, which correspond to some
> dummy entity
> type, which may have to be dynamically generated, which instances
> are tested
> by the particular test method.
>
> I would like to get an advice on the best way to express these
> semantics
> in MbUnit. I realize, that it may not be supported out of the box,
> but I
> have an impression, that even if MbUnit misses some functionality,
> the v3
> architecture provides numerous extension points, which can be
> utilized to
> add the missing logic.
>
> Thanks.
>
>
> >
========================================================================
==
There are two kinds of people. Those whose guns are loaded and those
who dig.
(The good, the bad and the ugly).
So let us raise our cups for our guns always be loaded.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
