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
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
