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
On 9 July 2013 19:45, Camillo Bruni <camillobruni@gmail.com> 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! frank
On 2013-07-09, at 21:23, Frank Shearar <frank.shearar@gmail.com> wrote:
On 9 July 2013 19:45, Camillo Bruni <camillobruni@gmail.com> 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)... I'll check my magic box..
On 09.07.2013, at 23:28, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-07-09, at 21:23, Frank Shearar <frank.shearar@gmail.com> wrote:
On 9 July 2013 19:45, Camillo Bruni <camillobruni@gmail.com> 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'll check my magic box..
On 2013-07-10, at 08:05, Max Leske <maxleske@gmail.com> wrote:
On 09.07.2013, at 23:28, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-07-09, at 21:23, Frank Shearar <frank.shearar@gmail.com> wrote:
On 9 July 2013 19:45, Camillo Bruni <camillobruni@gmail.com> 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 :)
On 10 juil. 2013, at 11:24, Camillo Bruni wrote:
On 2013-07-10, at 08:05, Max Leske <maxleske@gmail.com> wrote:
On 09.07.2013, at 23:28, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-07-09, at 21:23, Frank Shearar <frank.shearar@gmail.com> wrote:
On 9 July 2013 19:45, Camillo Bruni <camillobruni@gmail.com> 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?
participants (4)
-
Camille Teruel -
Camillo Bruni -
Frank Shearar -
Max Leske