[Pharo-project] Issue 3015: When a test is restarted in the debugger, #tearDown and #setUp and not send
Hi, I added a new issue (that I think it could be see as an improvement, not an issue) that is related to debugging a test case written with SUnit. The problem is that when you restart a test in the debugger (either by pressing the restart button or compiling the method again) the changes made by the test to the objects initialized in the #setUp are not rollbacked. This change sends the messages #tearDown and #setUp to the test when restarting it, therefore letting the test in the same state as when it was run in the first place. I uploaded the solution to this issue (or improvement) to pharo inbox under SLICE-Issue-3015-RestartingATestFromTheDebuggerSendsTearDownAndSetUp-HernanWilkinson.2 I hope you like it! Hernan. -- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*
Hernan, Isn't the idea of SUnit that you start with a fresh test each time? So you wouldn't restart a test (you could restart/re-run a suite of course). The only exception to starting fresh is the SUnit resource mechanism. Well, that's how I seem to remember the philosophy (I haven't used SUnit for some years). Peter On Thu, 30 Sep 2010 19:28:59 +0200, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
Hi, I added a new issue (that I think it could be see as an improvement, not an issue) that is related to debugging a test case written with SUnit. The problem is that when you restart a test in the debugger (either by pressing the restart button or compiling the method again) the changes made by the test to the objects initialized in the #setUp are not rollbacked.This change sends the messages #tearDown and #setUp to the test when restarting it, therefore letting the test in the same state as when it was run in the first place.
I uploaded the solution to this issue (or improvement) to pharo inbox under SLICE-Issue-3015-RestartingATestFromTheDebuggerSendsTearDownAndSetUp-HernanWilkinson.2
I hope you like it! Hernan.
--Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com
-- Peter van Rooijen Nijlring 83 5152 VJ Drunen m: 06-2854 2048
2010/10/6 Peter van Rooijen <peter@vanrooijen.com>
Hernan,
Isn't the idea of SUnit that you start with a fresh test each time? So you wouldn't restart a test (you could restart/re-run a suite of course).
The change I made is intended to help you when you are debugging a test. For example,in the current implementation when you modify the test while debugging it the test method restarts but (like any method that is restarted) but the method "environment" is not restarted, therefore running the test again could not produce the same result. The change I made send the messages #tearDown and #setUp to the test when it is restared "in the debugger", therefore it restarts the environment also
The only exception to starting fresh is the SUnit resource mechanism.
Well, that's how I seem to remember the philosophy (I haven't used SUnit for some years).
Peter
On Thu, 30 Sep 2010 19:28:59 +0200, Hernan Wilkinson < hernan.wilkinson@10pines.com> wrote:
Hi, I added a new issue (that I think it could be see as an improvement, not an issue) that is related to debugging a test case written with SUnit. The problem is that when you restart a test in the debugger (either by pressing the restart button or compiling the method again) the changes made by the test to the objects initialized in the #setUp are not rollbacked. This change sends the messages #tearDown and #setUp to the test when restarting it, therefore letting the test in the same state as when it was run in the first place.
I uploaded the solution to this issue (or improvement) to pharo inbox under SLICE-Issue-3015-RestartingATestFromTheDebuggerSendsTearDownAndSetUp-HernanWilkinson.2
I hope you like it! Hernan.
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*
-- Peter van Rooijen Nijlring 83 5152 VJ Drunen m: 06-2854 2048
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*
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-te... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (3)
-
Hernan Wilkinson -
otto -
Peter van Rooijen