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