On 10 juil. 2013, at 11:24, Camillo Bruni wrote: > > On 2013-07-10, at 08:05, Max Leske <[email protected]> wrote: > >> >> On 09.07.2013, at 23:28, Camillo Bruni <[email protected]> wrote: >> >>> >>> On 2013-07-09, at 21:23, Frank Shearar <[email protected]> wrote: >>> >>>> On 9 July 2013 19:45, Camillo Bruni <[email protected]> wrote: >>>>> I continue my rant with should:raise:description: >>>>> >>>>> a) self should: [ Error signal: 'error message' ] raise: Halt >>>>> description: 'message'. >>>>> b) self should: [ 1 + 2 ] raise: Halt >>>>> description: 'message'. >>>>> >>>>> In the first case you do not get the 'message' but 'error message'. >>>>> In the second case you get the 'message'. >>>>> >>>>> Does the description make sense in this case? >>>>> 1. if you signal Halt everything is fine >>>>> 2. Every other case is a failure >>>>> 3. In case a) an internal failure happens so the test fails anyway, fine, >>>>> but no description >>>>> 4. A strange? case where the tests actually DO pass but we nevertheless >>>>> want to print a description. >>>>> >>>>> Can anybody give me a convincing case for 4? >>>>> >>>>> Sorry, after this I will stop :D >>>> >>>> In case (a) I would actually expect to see something like: "message. >>>> Unexpected Error raised: 'error message'". >>>> >>>> In case (b) I'd want to see "message: no Halt raised" >>>> >>>> I can't think of why you would want a description for a success case, >>>> so #4 just seems weird! >>> >>> exactly! :) I agree on that ;). Now the question is on how to properly fix >>> this >>> for debugging. Since you actually want to debug on the unexpected Exception >>> in >>> case a)... >> >> >> YESSSS!! That's about the thing I hate the most about SUnit: if a testrun >> fails because #should: fails, the signaler context is gone. That's SO >> ANNYOING! > > I managed to solve this by added Exception >> #signalIn: aContext, like that > I can signal > an AssertionFailure with the proper error message in place of the original > error. so you get > 1) a proper error message in the debugger and test output > 2) the debugger opens at the very place the original exception was signaled :)
Excellent !! Have you checked that it doesn't break the create button in case of DNU?
