why? To me this does not make sense. I'd expect Error subclass: #AssertionFailure
+1 Maybe Halt et. al need to be put into a separate hierarchy (all of the classes the implement #defaultAction identically). On 23.05.2013, at 15:59, Camillo Bruni <camillobruni@gmail.com> wrote:
why? To me this does not make sense. I'd expect
Error subclass: #AssertionFailure
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. I would guess it has something to do with SUnit logic ? Sven
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.
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'...
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
Did you check the latest SUnit version before doing that ? I think it is not integrated yet in Pharo. 2013/5/23 Camillo Bruni <camillobruni@gmail.com>
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
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*
On 2013-05-23, at 20:15, Clément Bera <bera.clement@gmail.com> wrote:
Did you check the latest SUnit version before doing that ? I think it is not integrated yet in Pharo.
Yes I had a look at it, though not that much in detail. And I think not that much change on the global scale. I should check again I guess :)
participants (4)
-
Camillo Bruni -
Clément Bera -
Max Leske -
Sven Van Caekenberghe