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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project