You just need to override Execute, and replace the existing implementation (which handles ExpectedExceptions) with your own. It might be worth us pulling the exception handling code out into another hook method, to make this easier in future.
On 2 October 2010 15:35, Mark Kharitonov <[email protected]> wrote: > We already subclass the TestAttribute class (amongst others). The most > suitable place is the Consume override, but it seems complex. I hope > there is a better solution. > > On Oct 2, 3:34 pm, Graham Hay <[email protected]> wrote: > > I thought you could assert the InnerException as well, but that doesn't > > appear to have survived the transition from MbUnit > > v2< > http://www.gallio.org/api-v2/html/P_MbUnit_Framework_ExpectedExceptio...>. > > The easiest thing to do is probably to subclass/replace the TestAttribute > > with a custom version that satisfies your requirements, either by > stripping > > the outer exception or adding inner exception metadata to check. > > > > On 2 October 2010 12:33, Mark Kharitonov <[email protected]> > wrote: > > > > > Dear sirs. > > > We have a situation, where tests throw exceptions wrapped in a general > > > purpose exception. So that one has to specify this general purpose > > > exception in the [ExpectedException] attribute, rather than actual > > > business exception. > > > > > Only there is another complication. We have build a framework, where > > > individual tests are combined in scenarios using XML files. The same > > > test may appear several times in one scenario and the test input > > > specifies whether the test is expected to fail or not. So, there is > > > neither hard coded [ExpectedException] attribute nor Assert.Throws > > > statements in the code. (We dynamically add the expected exception > > > metadata when needed). > > > > > Anyway, the person creating the scenario (i.e. writing the XML file) > > > now has to indicate that the particular test is expected to fail with > > > some artificial exception (like ShunraDataPortalException) instead of > > > a specific business exception (like LastChangedMismatchException). > > > > > I was wondering if any of the following possible: > > > - Automatically and transparently wrap each test in a wrapper with > > > the same signature, that would try-execute-catch-strip-throw. > > > - Somehow modify the exception checking, to extract the actual > > > business exception before asserting the expected exception. > > > > > Thanks. > > > > > -- > > > 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]<mbunituser%[email protected]> > <mbunituser%[email protected]<mbunituser%[email protected]> > > > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/mbunituser?hl=en. > > -- > 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]<mbunituser%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/mbunituser?hl=en. > > -- 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.
