Smalltalk › Pharo › Pharo Smalltalk Developers

Issue 3015: When a test is restarted in the debugger, #tearDown and #setUp and not send

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Hernan Wilkinson-3

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: [hidden email]
site: http://www.10Pines.com

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse

Re: Issue 3015: When a test is restarted in the debugger, #tearDown and #setUp and not send

thanks hernan!

> 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!

Sounds good.

> Hernan.
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 911 - 4470 - 7207
> email: [hidden email]
> site: http://www.10Pines.com
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Peter van Rooijen

Re: Issue 3015: When a test is restarted in the debugger, #tearDown and #setUp and not send

In reply to this post by Hernan Wilkinson-3

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 <[hidden email]> 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: [hidden email]
site: http://www.10Pines.com

Peter van Rooijen
Nijlring 83
5152 VJ Drunen
m: 06-2854 2048

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hernan Wilkinson-3

Re: Issue 3015: When a test is restarted in the debugger, #tearDown and #setUp and not send

2010/10/6 Peter van Rooijen <[hidden email]>

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 <[hidden email]> 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: [hidden email]
site: http://www.10Pines.com

--
Peter van Rooijen
Nijlring 83
5152 VJ Drunen
m: 06-2854 2048

_______________________________________________
Pharo-project mailing list
[hidden email]
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: [hidden email]
site: http://www.10Pines.com

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

otto

Re: Issue 3015: When a test is restarted in the debugger, #tearDown and #setUp and not send

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