On 2013-05-23, at 16:37, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 May 2013, at 16:34, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-23, at 16:26, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 May 2013, at 15:59, Camillo Bruni <camillobruni@gmail.com> 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