Ken Causey <ken at ineffable.com> wrote:

> Is it too much to asks that the errors be listed (not just the test
> method, but the particular line that generated the error and the error
> message) in the TestRunner interface or at least in the Transcript?  The
> debug window is great, but in this case, if I'm using the TestRunner
> it's very likely that I already have a browser open and I'm probably
> even viewing the code that generated the error (test first development
> you know).  I really don't need the debug window in most cases, although
> an option to get one would be great.
> 

There are two classes of things SUnit flags: assertion failures, and
outright errors.  (This is the SUnit usage; failures might be called
errors too :))   It sounds like you are talking about assertion
failures, because full out errors will tend to put the debugger right at
the offending location.  You are seeing cases where the offending code
is no longer on the execution stack, which sounds like an asesrtion
failure.

For an assertion failure, I'm not sure what SUnit *should* send you too.
 The expression that the assertion is checking succeeded; it simply
produced the wrong value.  Putting you in a debugger at the place of the
assert: call seems about as good as it can do.

Note that once you are in this location, you can get to a lot of
browsers very quickly with alt-b and alt-i.  For example, if this is
part of your test method that failed:

	x = y ifTrue: [
		self assert: [ x hash = y hash ] ]

You could highlight "x" in one of the bottom two panes and hit alt-b to
get to a browser.  For a more complicated example:

	self assert: [ x boundingConic isContainedIn: y boundingConic ]

Here you might highlight "x boundingConic", hit alt-i, and then use
alt-b in the resulting browser.  You could repeat with "y boundingConic"
if it is a different class.


For what it's worth, I love starting from a debugger.  It's easy to get
to browsers when necessary, and it is very nice to have live values to
play with as examples.

Also for whatever it's worth, I don't like step-ing and send-ing around
much, myself.  :)  Usually I do a lot of debugging and browsing,
followed by changing some code somewhere and then doing a method
restart.  Stepping and sending just takes too long.


  -Lex