Making pharo more tdd oriented

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Making pharo more tdd oriented

hernan.wilkinson
Hi,
 I have made some changes to pharo to make it more tdd oriented. I want to share them with you to know your opinion and then make the code public.
 The changes I made are:

1) When there is an error, the debugger opens directly. Reason: I found that I always press Debug when an error occurs in the Notifier window. Question: Should this option be a preference?
2) The debugger opens in a big window. Reason: I always want to debug! and I want to see as much as possible when debugging. Before I found myself making the debugger window bigger all the time
3) When compiling a method that sends a message not defined, it does not ask anymore if I want to change it. Reason: When doing TDD we work top-down, so we are always sending messages that are not defined and that we are going to define when running the test. Question: Should this option be a preference?
4) I added an option to save and run the test from the code pane of the omni browser (ctr+t). If the test fails, opens a debugger to fix it. Reason: It is very handful
5) I added an option to save and step a test from the code pane of the omni browser (ctrl+r). Reason: It is very handful (Problem: The debugger does not work well with breakpoints...)
6) I added a debugCase: message to TestResult and make some changes to the omni browser to show the result of debugging a test. Reason: Before, when debugging a test the browser was showing the test as not runned.
7) When running a test, the defualtAction of the MessageNotUndertood exception will ask you if you want to implement the method (if the receiver is not nil) so you don't have to select that option from the debugger stack list menu. Reason: When running a test 95% of the time a message not understood will be implemented and answering yes or no is easier that going to the stack menu of the debugger to select the option implement.

 What do you think? Comments welcome.
 Bye,
 Hernan.





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

David Mitchell-10
1. +1 Direct to debug sounds good to me. Notifier window was for low power (in the 1980s). Don't care if it is a preference. Would prefer fewer preferences, but I can't bring myself to add a preference for it...
2. +1 Big Debugger.
3. -1 I work top-down as well and I still like the typo correction that comes from this step.
4. +1 Wish shortcuts weren't pane specific.
5. ?
6. ?
7. +1

2009/6/18 Hernan Wilkinson <[hidden email]>
Hi,
 I have made some changes to pharo to make it more tdd oriented. I want to share them with you to know your opinion and then make the code public.
 The changes I made are:

1) When there is an error, the debugger opens directly. Reason: I found that I always press Debug when an error occurs in the Notifier window. Question: Should this option be a preference?
2) The debugger opens in a big window. Reason: I always want to debug! and I want to see as much as possible when debugging. Before I found myself making the debugger window bigger all the time
3) When compiling a method that sends a message not defined, it does not ask anymore if I want to change it. Reason: When doing TDD we work top-down, so we are always sending messages that are not defined and that we are going to define when running the test. Question: Should this option be a preference?
4) I added an option to save and run the test from the code pane of the omni browser (ctr+t). If the test fails, opens a debugger to fix it. Reason: It is very handful
5) I added an option to save and step a test from the code pane of the omni browser (ctrl+r). Reason: It is very handful (Problem: The debugger does not work well with breakpoints...)
6) I added a debugCase: message to TestResult and make some changes to the omni browser to show the result of debugging a test. Reason: Before, when debugging a test the browser was showing the test as not runned.
7) When running a test, the defualtAction of the MessageNotUndertood exception will ask you if you want to implement the method (if the receiver is not nil) so you don't have to select that option from the debugger stack list menu. Reason: When running a test 95% of the time a message not understood will be implemented and answering yes or no is easier that going to the stack menu of the debugger to select the option implement.

 What do you think? Comments welcome.
 Bye,
 Hernan.





_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

Schwab,Wilhelm K
In reply to this post by hernan.wilkinson
 Hernan,
 
(1) going straight to a debugger is a really bad idea.  Object Arts tried it, and promptly spoke out against it.  If you want the option to skip the notifier, fine, but I want to the option to keep the buffer of the notifier.  Imagine a recursive meltdown, and then make it an order of magnitude or two worse because every mention of the problem is a full debugger instead of a notifier.  You've been warned :)

(2) +1, maybe 2

(3) +3 :)  Those prompts are seriously annoying.  I even have places in my code that look like
 
    uninitializeTemp := uninitializeTemp.
 
just to gag the "is it ok to remove xyz".  It arises when I capture something in a temp knowing that I will need it later but have not coded that far yet.  Not quite TTD, but not all that different.

(4-5) options are generally good things.

 
(6) Is there any impact on performance?  OB is too slow as it is.  Otherwise it's probably fine.
 
(7) I'm not a big fan of the default action concept, but this is probably a good use.  That said, I would probably not want to use it, and would ask that you make it optional.  From a system stability standpoint, I am a little nervous about having an error invoke the GUI, especially if the tests make use of #fork: etc.
 
Bill
 
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Hernan Wilkinson
Sent: Thursday, June 18, 2009 4:09 PM
To: [hidden email]
Subject: [Pharo-project] Making pharo more tdd oriented

Hi,
 I have made some changes to pharo to make it more tdd oriented. I want to share them with you to know your opinion and then make the code public.
 The changes I made are:

1) When there is an error, the debugger opens directly. Reason: I found that I always press Debug when an error occurs in the Notifier window. Question: Should this option be a preference?
2) The debugger opens in a big window. Reason: I always want to debug! and I want to see as much as possible when debugging. Before I found myself making the debugger window bigger all the time
3) When compiling a method that sends a message not defined, it does not ask anymore if I want to change it. Reason: When doing TDD we work top-down, so we are always sending messages that are not defined and that we are going to define when running the test. Question: Should this option be a preference?
4) I added an option to save and run the test from the code pane of the omni browser (ctr+t). If the test fails, opens a debugger to fix it. Reason: It is very handful
5) I added an option to save and step a test from the code pane of the omni browser (ctrl+r). Reason: It is very handful (Problem: The debugger does not work well with breakpoints...)
6) I added a debugCase: message to TestResult and make some changes to the omni browser to show the result of debugging a test. Reason: Before, when debugging a test the browser was showing the test as not runned.
7) When running a test, the defualtAction of the MessageNotUndertood exception will ask you if you want to implement the method (if the receiver is not nil) so you don't have to select that option from the debugger stack list menu. Reason: When running a test 95% of the time a message not understood will be implemented and answering yes or no is easier that going to the stack menu of the debugger to select the option implement.

 What do you think? Comments welcome.
 Bye,
 Hernan.





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

Schwab,Wilhelm K
In reply to this post by David Mitchell-10
David,
 
Re (1), I must respectfully disagrree - Object Arts' experience was much more recent than the 80's, and they have never been shy about keeping up on hardware.  They reached a surprisingly rapid and passionate conclusion in favor of the notifier.  If you want an option to go straight to the debugger, that's fine by me, just warn me so I can turn it off.
 
Bill
 
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of David Mitchell
Sent: Thursday, June 18, 2009 5:06 PM
To: [hidden email]
Subject: Re: [Pharo-project] Making pharo more tdd oriented

1. +1 Direct to debug sounds good to me. Notifier window was for low power (in the 1980s). Don't care if it is a preference. Would prefer fewer preferences, but I can't bring myself to add a preference for it...
2. +1 Big Debugger.
3. -1 I work top-down as well and I still like the typo correction that comes from this step.
4. +1 Wish shortcuts weren't pane specific.
5. ?
6. ?
7. +1

2009/6/18 Hernan Wilkinson <[hidden email]>
Hi,
 I have made some changes to pharo to make it more tdd oriented. I want to share them with you to know your opinion and then make the code public.
 The changes I made are:

1) When there is an error, the debugger opens directly. Reason: I found that I always press Debug when an error occurs in the Notifier window. Question: Should this option be a preference?
2) The debugger opens in a big window. Reason: I always want to debug! and I want to see as much as possible when debugging. Before I found myself making the debugger window bigger all the time
3) When compiling a method that sends a message not defined, it does not ask anymore if I want to change it. Reason: When doing TDD we work top-down, so we are always sending messages that are not defined and that we are going to define when running the test. Question: Should this option be a preference?
4) I added an option to save and run the test from the code pane of the omni browser (ctr+t). If the test fails, opens a debugger to fix it. Reason: It is very handful
5) I added an option to save and step a test from the code pane of the omni browser (ctrl+r). Reason: It is very handful (Problem: The debugger does not work well with breakpoints...)
6) I added a debugCase: message to TestResult and make some changes to the omni browser to show the result of debugging a test. Reason: Before, when debugging a test the browser was showing the test as not runned.
7) When running a test, the defualtAction of the MessageNotUndertood exception will ask you if you want to implement the method (if the receiver is not nil) so you don't have to select that option from the debugger stack list menu. Reason: When running a test 95% of the time a message not understood will be implemented and answering yes or no is easier that going to the stack menu of the debugger to select the option implement.

 What do you think? Comments welcome.
 Bye,
 Hernan.





_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

Carlos Crosetti-4
In reply to this post by hernan.wilkinson
music to my ears.... :)
1) yes, make it a preference
2) concour
3 thru 7) no opinion
 
very thanks
-----Mensaje original-----
De: [hidden email] [mailto:[hidden email]]En nombre de Hernan Wilkinson
Enviado el: Jueves, 18 de Junio de 2009 06:09 p.m.
Para: [hidden email]
Asunto: [Pharo-project] Making pharo more tdd oriented

Hi,
 I have made some changes to pharo to make it more tdd oriented. I want to share them with you to know your opinion and then make the code public.
 The changes I made are:

1) When there is an error, the debugger opens directly. Reason: I found that I always press Debug when an error occurs in the Notifier window. Question: Should this option be a preference?
2) The debugger opens in a big window. Reason: I always want to debug! and I want to see as much as possible when debugging. Before I found myself making the debugger window bigger all the time
3) When compiling a method that sends a message not defined, it does not ask anymore if I want to change it. Reason: When doing TDD we work top-down, so we are always sending messages that are not defined and that we are going to define when running the test. Question: Should this option be a preference?
4) I added an option to save and run the test from the code pane of the omni browser (ctr+t). If the test fails, opens a debugger to fix it. Reason: It is very handful
5) I added an option to save and step a test from the code pane of the omni browser (ctrl+r). Reason: It is very handful (Problem: The debugger does not work well with breakpoints...)
6) I added a debugCase: message to TestResult and make some changes to the omni browser to show the result of debugging a test. Reason: Before, when debugging a test the browser was showing the test as not runned.
7) When running a test, the defualtAction of the MessageNotUndertood exception will ask you if you want to implement the method (if the receiver is not nil) so you don't have to select that option from the debugger stack list menu. Reason: When running a test 95% of the time a message not understood will be implemented and answering yes or no is easier that going to the stack menu of the debugger to select the option implement.

 What do you think? Comments welcome.
 Bye,
 Hernan.





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

Alain Plantec-4
In reply to this post by hernan.wilkinson
sorry but what is the meaning of "TDD" ?
Alain

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

NorbertHartl
On Fri, 2009-06-19 at 08:58 +0200, Alain Plantec wrote:
> sorry but what is the meaning of "TDD" ?

It is test driven development.

Norbert


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

laurent laffont
In reply to this post by Alain Plantec-4
Hi,

It means Test Driven Development. It defines the process of writing the unit test before writing the "real code". The steps are roughly:
1. write a test for a feature you want. For example, "when I add a Movie instance to an empty Movies collection, then Movies size should increase by one"
2. check your test fails (in most cases) as you still haven't implement your feature
3. write the real code (the simplest that should make your test pass)
4. check your test pass
5. refactor both real code and test code, generally searching for code duplication.

This enables that:
- most of your code and cases is tested
- simpler code
- confidence in your code
- quicker development as you immediately know when something breaks, thus less debugging.

A book I've learned a lot from is Dave Astels's Test Driven Development: A practical guide.

Laurent Laffont

On Fri, Jun 19, 2009 at 8:58 AM, Alain Plantec <[hidden email]> wrote:
sorry but what is the meaning of "TDD" ?
Alain

_______________________________________________
Pharo-project mailing list


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

Denis Kudriashov
In reply to this post by hernan.wilkinson


1) When there is an error, the debugger opens directly. Reason: I found that I always press Debug when an error occurs in the Notifier window. Question: Should this option be a preference?

I like VW behavior. There are three buttons: debug, run, step.
When I do debug and there is an error in some test, the debugger opens directly. And when I press debugger proceed, tests continue execution.
When I do run, all failed tests are collected to the list. And button "show failed" appears.
When I do step the debugger open on the begin of test.

I think it is ideal browser behavior for TDD support. In some squeak version (maiby 3.8) there is special services fo this. But now it is absent

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

Stéphane Ducasse
In reply to this post by hernan.wilkinson
I should say that I hate the popups "do you want to do that or remove  
this variable but wait it is assigned tooo."

May be we should have a menu
        clean code!
        but for now let is accept it


> Hi,
>  I have made some changes to pharo to make it more tdd oriented. I  
> want to share them with you to know your opinion and then make the  
> code public.
>  The changes I made are:
>
> 1) When there is an error, the debugger opens directly. Reason: I  
> found that I always press Debug when an error occurs in the Notifier  
> window. Question: Should this option be a preference?

I'm not sure in fact because when you are not in TDD you just often  
close the predebug.
but we could change.

> 2) The debugger opens in a big window. Reason: I always want to  
> debug! and I want to see as much as possible when debugging. Before  
> I found myself making the debugger window bigger all the time

larger but not to big :)

> 3) When compiling a method that sends a message not defined, it does  
> not ask anymore if I want to change it. Reason: When doing TDD we  
> work top-down, so we are always sending messages that are not  
> defined and that we are going to define when running the test.  
> Question: Should this option be a preference?

No preference. Now if the system could guess typos :)


> 4) I added an option to save and run the test from the code pane of  
> the omni browser (ctr+t). If the test fails, opens a debugger to fix  
> it. Reason: It is very handful

Yes right now when you do alt-t you run the test but you cannot get a  
debugger on them.
I would love to
        click to run the tests
        get a small widgets with the result of the execution and that I can  
rerun or get a debugger on the tests.


> 5) I added an option to save and step a test from the code pane of  
> the omni browser (ctrl+r). Reason: It is very handful (Problem: The  
> debugger does not work well with breakpoints...)
> 6) I added a debugCase: message to TestResult and make some changes  
> to the omni browser to show the result of debugging a test. Reason:  
> Before, when debugging a test the browser was showing the test as  
> not runned.

sounds interesting

> 7) When running a test, the defualtAction of the MessageNotUndertood  
> exception will ask you if you want to implement the method (if the  
> receiver is not nil) so you don't have to select that option from  
> the debugger stack list menu. Reason: When running a test 95% of the  
> time a message not understood will be implemented and answering yes  
> or no is easier that going to the stack menu of the debugger to  
> select the option implement.

in Squeak we could show the class and its superclass.

>
>  What do you think? Comments welcome.
>  Bye,
>  Hernan.
>
>
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

hernan.wilkinson
In reply to this post by Schwab,Wilhelm K
Hi Bill,
 thank you for your answer!
 There is no performance penalty on the OB.
 I'll think I'll add a button to the debugger to define the method. Same behavior as now but instead of going to the stack menu, just a button, much more faster.
 About the notifier, why did Object Arts went back? Are there any mail/info related? And I do not understand the recursive problem you mention, the debugger stops the process, why would it be different from a notifier?

 Bye,
 Hernan.

2009/6/18 Schwab,Wilhelm K <[hidden email]>
 Hernan,
 
(1) going straight to a debugger is a really bad idea.  Object Arts tried it, and promptly spoke out against it.  If you want the option to skip the notifier, fine, but I want to the option to keep the buffer of the notifier.  Imagine a recursive meltdown, and then make it an order of magnitude or two worse because every mention of the problem is a full debugger instead of a notifier.  You've been warned :)

(2) +1, maybe 2

(3) +3 :)  Those prompts are seriously annoying.  I even have places in my code that look like
 
    uninitializeTemp := uninitializeTemp.
 
just to gag the "is it ok to remove xyz".  It arises when I capture something in a temp knowing that I will need it later but have not coded that far yet.  Not quite TTD, but not all that different.

(4-5) options are generally good things.

 
(6) Is there any impact on performance?  OB is too slow as it is.  Otherwise it's probably fine.
 
(7) I'm not a big fan of the default action concept, but this is probably a good use.  That said, I would probably not want to use it, and would ask that you make it optional.  From a system stability standpoint, I am a little nervous about having an error invoke the GUI, especially if the tests make use of #fork: etc.
 
Bill
 
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Hernan Wilkinson
Sent: Thursday, June 18, 2009 4:09 PM
To: [hidden email]
Subject: [Pharo-project] Making pharo more tdd oriented

Hi,
 I have made some changes to pharo to make it more tdd oriented. I want to share them with you to know your opinion and then make the code public.
 The changes I made are:

1) When there is an error, the debugger opens directly. Reason: I found that I always press Debug when an error occurs in the Notifier window. Question: Should this option be a preference?
2) The debugger opens in a big window. Reason: I always want to debug! and I want to see as much as possible when debugging. Before I found myself making the debugger window bigger all the time
3) When compiling a method that sends a message not defined, it does not ask anymore if I want to change it. Reason: When doing TDD we work top-down, so we are always sending messages that are not defined and that we are going to define when running the test. Question: Should this option be a preference?
4) I added an option to save and run the test from the code pane of the omni browser (ctr+t). If the test fails, opens a debugger to fix it. Reason: It is very handful
5) I added an option to save and step a test from the code pane of the omni browser (ctrl+r). Reason: It is very handful (Problem: The debugger does not work well with breakpoints...)
6) I added a debugCase: message to TestResult and make some changes to the omni browser to show the result of debugging a test. Reason: Before, when debugging a test the browser was showing the test as not runned.
7) When running a test, the defualtAction of the MessageNotUndertood exception will ask you if you want to implement the method (if the receiver is not nil) so you don't have to select that option from the debugger stack list menu. Reason: When running a test 95% of the time a message not understood will be implemented and answering yes or no is easier that going to the stack menu of the debugger to select the option implement.

 What do you think? Comments welcome.
 Bye,
 Hernan.





_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

hernan.wilkinson
In reply to this post by Stéphane Ducasse


On Fri, Jun 19, 2009 at 7:32 AM, Stéphane Ducasse <[hidden email]> wrote:
I should say that I hate the popups "do you want to do that or remove
this variable but wait it is assigned tooo."

May be we should have a menu
       clean code!
       but for now let is accept it

I agree with that. When coding I do not pay to much attention to those things because after I'm done (or I thing the code is stable enough) I run SmallLint to fix all those things.... When I'm coding I want to be as fast as possible... of course, not everybody has to agree with this.




> Hi,
>  I have made some changes to pharo to make it more tdd oriented. I
> want to share them with you to know your opinion and then make the
> code public.
>  The changes I made are:
>
> 1) When there is an error, the debugger opens directly. Reason: I
> found that I always press Debug when an error occurs in the Notifier
> window. Question: Should this option be a preference?

I'm not sure in fact because when you are not in TDD you just often
close the predebug.
but we could change.

But what is the difference with closing the debugger?
I worked with VisualAge that does not have the notifier and now with pharo/squeak I feel the notifier bothers me...
 


> 2) The debugger opens in a big window. Reason: I always want to
> debug! and I want to see as much as possible when debugging. Before
> I found myself making the debugger window bigger all the time

larger but not to big :)

> 3) When compiling a method that sends a message not defined, it does
> not ask anymore if I want to change it. Reason: When doing TDD we
> work top-down, so we are always sending messages that are not
> defined and that we are going to define when running the test.
> Question: Should this option be a preference?

No preference. Now if the system could guess typos :)


> 4) I added an option to save and run the test from the code pane of
> the omni browser (ctr+t). If the test fails, opens a debugger to fix
> it. Reason: It is very handful

Yes right now when you do alt-t you run the test but you cannot get a
debugger on them.

Yes, but alt-t is if the focus is on the method list (or category list or class list or package list).  The option I added is when the focus is in the code panel


I would love to
       click to run the tests
       get a small widgets with the result of the execution and that I can
rerun or get a debugger on the tests.

I did this:
1) you write the test
2) when done, press ctr+t (I could not make alt+t) work...
3) It will not ask you for bad selectors (your are doing tdd, so you are sending messages that are not implemented)
4) It will save the method
5) Run the test. If it runs ok, the green button will appear on the method list
6) If it fails or err, the yellow/red button will appear on the method list and the debugger will open
7) If you fix the error, go to 3 :-).

I think it is very helpful and agile. If you want to steep the test, just press ctrl+r
 


> 7) When running a test, the defualtAction of the MessageNotUndertood
> exception will ask you if you want to implement the method (if the
> receiver is not nil) so you don't have to select that option from
> the debugger stack list menu. Reason: When running a test 95% of the
> time a message not understood will be implemented and answering yes
> or no is easier that going to the stack menu of the debugger to
> select the option implement.

in Squeak we could show the class and its superclass.

Yes, but I found that I always implement the method in the class not in any of it superclasses...

Anyway, I know it is not easy to satisfy everybody... I'll publish the code in squeak source so everybody can try it and give me feedback and make it better.

Bye,
Hernan.
 


>
>  What do you think? Comments welcome.
>  Bye,
>  Hernan.
>
>
>
>
> _______________________________________________
> 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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Making pharo more tdd oriented

Schwab,Wilhelm K
In reply to this post by hernan.wilkinson
Hernan,
 
A separate command in the debugger sounds like a great idea; that way it is accessible with none of the down side of prompting.
 
There probably is a trail that I can find on OA's reaction to bypassing notifiers.  IIRC, they were getting a lot of pressure to allow the option, added it,
and almost immediately said "it's available - use at your own risk."
 
The recursive situations involve another error triggered either by failing to clear some condition or simply by shaking up the display by moving windows
around as the notifier/debugger opens.  IMHO, any prayer of breaking out depends on having the lightweight notifiers vs. full debuggers trying to open.
 
Bill
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Hernan Wilkinson
Sent: Friday, June 19, 2009 12:32 PM
To: [hidden email]
Subject: Re: [Pharo-project] Making pharo more tdd oriented

Hi Bill,
 thank you for your answer!
 There is no performance penalty on the OB.
 I'll think I'll add a button to the debugger to define the method. Same behavior as now but instead of going to the stack menu, just a button, much more faster.
 About the notifier, why did Object Arts went back? Are there any mail/info related? And I do not understand the recursive problem you mention, the debugger stops the process, why would it be different from a notifier?

 Bye,
 Hernan.

2009/6/18 Schwab,Wilhelm K <[hidden email]>
 Hernan,
 
(1) going straight to a debugger is a really bad idea.  Object Arts tried it, and promptly spoke out against it.  If you want the option to skip the notifier, fine, but I want to the option to keep the buffer of the notifier.  Imagine a recursive meltdown, and then make it an order of magnitude or two worse because every mention of the problem is a full debugger instead of a notifier.  You've been warned :)

(2) +1, maybe 2

(3) +3 :)  Those prompts are seriously annoying.  I even have places in my code that look like
 
    uninitializeTemp := uninitializeTemp.
 
just to gag the "is it ok to remove xyz".  It arises when I capture something in a temp knowing that I will need it later but have not coded that far yet.  Not quite TTD, but not all that different.

(4-5) options are generally good things.

 
(6) Is there any impact on performance?  OB is too slow as it is.  Otherwise it's probably fine.
 
(7) I'm not a big fan of the default action concept, but this is probably a good use.  That said, I would probably not want to use it, and would ask that you make it optional.  From a system stability standpoint, I am a little nervous about having an error invoke the GUI, especially if the tests make use of #fork: etc.
 
Bill
 
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Hernan Wilkinson
Sent: Thursday, June 18, 2009 4:09 PM
To: [hidden email]
Subject: [Pharo-project] Making pharo more tdd oriented

Hi,
 I have made some changes to pharo to make it more tdd oriented. I want to share them with you to know your opinion and then make the code public.
 The changes I made are:

1) When there is an error, the debugger opens directly. Reason: I found that I always press Debug when an error occurs in the Notifier window. Question: Should this option be a preference?
2) The debugger opens in a big window. Reason: I always want to debug! and I want to see as much as possible when debugging. Before I found myself making the debugger window bigger all the time
3) When compiling a method that sends a message not defined, it does not ask anymore if I want to change it. Reason: When doing TDD we work top-down, so we are always sending messages that are not defined and that we are going to define when running the test. Question: Should this option be a preference?
4) I added an option to save and run the test from the code pane of the omni browser (ctr+t). If the test fails, opens a debugger to fix it. Reason: It is very handful
5) I added an option to save and step a test from the code pane of the omni browser (ctrl+r). Reason: It is very handful (Problem: The debugger does not work well with breakpoints...)
6) I added a debugCase: message to TestResult and make some changes to the omni browser to show the result of debugging a test. Reason: Before, when debugging a test the browser was showing the test as not runned.
7) When running a test, the defualtAction of the MessageNotUndertood exception will ask you if you want to implement the method (if the receiver is not nil) so you don't have to select that option from the debugger stack list menu. Reason: When running a test 95% of the time a message not understood will be implemented and answering yes or no is easier that going to the stack menu of the debugger to select the option implement.

 What do you think? Comments welcome.
 Bye,
 Hernan.





_______________________________________________
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