[Pharo-dev] Issue 3015: When a test is restarted in the debugger, #tearDown and #setUp and not send

otto otto at finworks.biz
Wed Aug 28 07:43:34 EDT 2013


I just ran into an unexpected result because of this change, using pharo
1.4. Not sure if this has changed in pharo 2 / 3.

I was debugging a test method which failed an assertion inside a block in
the test method. When I restarted in the debugger, the execution restarted
the block (and not the test method). To my suprise, all the changes that the
test method did was gone, and I discovered this code.

I know that this may be useful to some people, but I think this is an ugly
hack and should be taken out. 

Where ever I restart a method (whether in a test or not), I don't expect
some resetting of the environment / state to the execution point where I'm
going. Everybody should be aware that when restarting a method or a block in
the debugger, you will have side effects up to the restart that you cannot
simply revert.

To restart a method (or a block!!) in a debugger is a goto. I know that.

Here's an example of what failed:

  self doSomething.
  User someone whileLoggedInDo: [ self assert: false ]

When the debugger pops up on the failed assert in the block, and I restart,
execution jumps to the beginning of the block (as expected). The unexpected
bit was when the test tearDown & setUp was run (of course without calling

What do you think?


View this message in context: http://forum.world.st/Issue-3015-When-a-test-is-restarted-in-the-debugger-tearDown-and-setUp-and-not-send-tp2732543p4705421.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

More information about the Pharo-dev mailing list