Yes, you are right. Execute is the right place, however, this function is not trivial. At least all that code around the failure logging plus the various checks. I wish I could make a more simple override.
On Oct 2, 4:59 pm, Graham Hay <[email protected]> wrote: > 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.
