Bryce Kampjes wrote:
Colin Putney writes:
>  >  I'd suggest to you, however, that the
functionality
>  you
>  >  describe is not "missing" from SUnit, so much as
>  >  unnecessary. Bringing up a debugger on the site
of a
>  >  failed assertion or an error is a very efficient
way
>  to
>  >  find and fix problems. It's even easier to
deduce why
>  >  the test failed in a debugger, and you can fix
it on
>  >  the spot.

I'm not trying to suggest that what you describe isn't
a very efficient way to find and fix problems. I just
suggesting that being able to view a summary of the
expected and actual results of failed tests within
sUnit's TestRunner Window (or in a Transcript) could
be useful. Often, I've found it isn't necessary to
step through the test code in order to see what's
broken. Bringing up the debugger and discovering the
actual and expected values on failed tests takes
several more clicks than it would of taken if that
info was displayed in sUnit. Having browsers open on
one's test case and class undergoing tests along with
sUnit displaying actual & expected info would, in many
instances, allow for a faster run test->write/fix code
(or even fix test) cycle. In such a set up you could
fix the problem "on the spot" faster in cases where
the comparison of expected and actual results leads to
a immediate correct deduction of what was wrong (such
as in a spelling mistake made in the test's expected
result).

>  The best way to explain this would probably be to
>  pair...

Yes, that sounds like a good way to make clear the
efficient use of debugger and sUnit. However, I don't
know any Smalltalkers where I live. Perhaps, I should
look into seeing if there's a local Smalltalker Users
Group.

Thanks for your advice,

Anthony


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