Viewing Failures in sUnit's TestRunner

Anthony Adachi adachipro at yahoo.com
Sun May 4 17:36:58 UTC 2003


Bryce Kampjes wrote:

>  It's good practice in Smalltalk to write code
inside the
>  debugger. Often I'll write a test, it fails,
knowing
>  that I'm going to
>  extend an existing method, I add a "self halt." to
the
>  start of
>  it. Rerunning the test, it stops at the halt in a
>  debugger. Then I add
>  the new code inside the debugger. This way I can
>  inspect the current
>  state and check it's what I think it should be. It
also
>  checks that
>  the method was really used by that test.

Yes, it can be valuable to step through one's code and
one can make discoveries in doing so. However, often
I've found it unnecessary and unwarranted. One of the
ideas behind Test Driven Development is that one
creates interfaces that one wishes one's code to have.
One focuses on interfaces and tries not to get to
wrapped up in implementation when writing and running
a test. An xUnit which allows the display of expected
and actual results helps to achieve this goal. In
that, at the point of a failed test, one's immediate
focus is on what they expected vs. what they got. Not
on how that came to be. 

At that moment, one should be wearing the testing hat
not the coding hat. 

If one immediately jumps into the implementation just
to find out what was the actual result in order to
compare with the expected they're going to be wearing
two hats at that point.

>  Learn to ask the machine questions. Sometimes
figuring
>  out how to ask
>  slows you down a little but soon you stop thinking
so
>  hard until
>  something unexpected happens then you have time to
>  think really hard.

I agree but writing and running tests is asking the
code questions. However, stepping through code is not.
That's observing how something gets done.

>  If a method breaks, I just click on it. A debugger
>  opens up, where I
>  make my changes. That way I don't need to remember
>  where the method is. 

Yes, that can be helpful.

>  (I've removed the halt from the interface, most of
the
>  time I
>  don't want to step through the method, so most of
the
>  time it's a waste of time.)

Jumping into the debugger to see actual vs. expected
results can cause a loss of focus (from interface to
implementation). At least that what often happens to
me.

>  When writing code in the debugger it is possible to
>  execute parts of
>  it there and then. So if an expression is causing
you
>  grief, just
>  execute that single expression. Very fast feedback.

I like this feature of Smallltalk.

>  I try and write all new code in the debugger. Code
>  browsers are only
>  for reading and refactoring code.

For when I'm wearing my coding hat I'm trying to
figure out where best to write code. The suggestion of
in the debugger sounds good.

Ned Konz wrote:

>  There is a package on SqueakMap that lets you set
>  breakpoints on entry without changing the source.
>  
>  It's called "Breakpoint support".

That would be very useful.

Thanks,

Anthony

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



More information about the Squeak-dev mailing list