On 2013-05-23, at 16:37, Sven Van Caekenberghe <[email protected]> wrote:
> > On 23 May 2013, at 16:34, Camillo Bruni <[email protected]> wrote: > >> >> On 2013-05-23, at 16:26, Sven Van Caekenberghe <[email protected]> wrote: >> >>> >>> On 23 May 2013, at 15:59, Camillo Bruni <[email protected]> wrote: >>> >>>> why? To me this does not make sense. I'd expect >>>> >>>> Error subclass: #AssertionFailure >>> >>> Yeah, I have asked myself the same question quite often. >>> >>> I often write self assert: <some condition> in production code, but then an >>> #on:do: handler specifying only Error won't catch the AssertionFailure >>> exceptions. >> >> exactly! I'm going to propose a fix, because I hate to write >> Error,AssertionFailure :P >> >>> I would guess it has something to do with SUnit logic ? >> >> >> Must be some strange leftover, since in interactive mode there is no >> distinction between Halt and any other Error. > > But doesn't TestRunner react differently on AssertionError as opposed to > other Errors ? The former are called 'Failures', the latter 'Errors'... I just checked. Using Halt and AssertionFailures directly in a test does mark the test as a failure, but it doesn't change anything on the existing #assert: inside testcases directly. Before: RBFormatterTests>>#testHalt Halt RBFormatterTests>>#testAssertionFailure AssertionFailure RBFormatterTests>>#testAssert TestFailure: Assertion failed After: RBFormatterTests>>#testHalt Halt RBFormatterTests>>#testAssertionFailure AssertionFailure RBFormatterTests>>#testAssert TestFailure: Assertion failed The only difference is in UI mode, when there is an AssertionFailure the test wasn't immediately marked RED. IMO this is not correct, as a failing assertion anywhere outside the code is an Error. But that was the case before (on the command line). So I would apply this change and maybe improve SUnit to deal with AssertionFailures from outside TestCases
