To be honest, it looks worse than it is. The whole method is dedicated to one purpose, executing a test and catching an exception if required, which is the behaviour you're looking to modify. We could probably break it up into a couple of overridable methods, but I'm loath to undo all Jeff's good work in reducing the stack depth.
On 2 October 2010 20:09, Mark Kharitonov <[email protected]> wrote: > Yep, the more I look at the Execute method the less I want to override > it. Too much internal logic to copy/paste. > > On Oct 2, 9:03 pm, Mark Kharitonov <[email protected]> wrote: > > 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]> > > > > > > <mbunituser%[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]> > <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.
