Hi, 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: testSomething 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 doSomething. What do you think? Cheers Otto -- 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.
