Why does SUnitBrowserResult not just use a TestResult?

I'm being a bit thick - but am trying to get my head around the
SUnitBrowser - as it bugs me that I have to click on the debug button to see
what error occured in a test (Way too many extra clicks going on for smooth
developement).

Its a bit limiting that in SUnit they don't store the descriptions (in the
TestResult) of any exceptions when they run a test (I shall propose this to
them) - for now I've hacked it in.

However I'm scratching my head over SUnitBrowserResult - it seems to copy
everything from a TestResult into itself (and then after this it does lots
of lookuptable stuff which makes it quite difficult to read).

Am I missing something here? Was the aim to not be linked to SUnit... but
then its called an SUnitBrowserResult. I would have thought that #merge:for:
would then go away (or greatly slim down).

sincerely, confused in Camden

"TimM" <[hidden email]> wrote in message
news:[hidden email]...
No idea, sorry. You'll have to try contacting Jeff Odell (see the package
comment).

Regards

Blair

> No idea, sorry. You'll have to try contacting Jeff Odell (see the package
> comment).

Oops - didn't notice that, have relayed a message to him (not sure if he's
around much though). I managed to figure out what I needed to do, but I
think the real issue is that the model he's used for the browser (which are
backed by SUnit - TestCases and Suites aren't really appropriate and so it
gets a bit smelly).

Still - a bit of hacking has given me a TestBrowser that shows test failures
in the status bar without having to run the debugger all the time.

Now have to find where I saw that message that shows how to add inst vars to
a class dynamically and figure out an easy way to stomp over a few methods
when I load my package. (some string resource and then a Compiler compile: ?
in my postInstall script - ugly but just a temp measure while I see if I can
get the SUnit guys to add something for remembering errors).

Tim

Tim,

> Now have to find where I saw that message that shows how to add inst vars to
> a class dynamically and figure out an easy way to stomp over a few methods
> when I load my package. (some string resource and then a Compiler compile: ?
> in my postInstall script - ugly but just a temp measure while I see if I can
> get the SUnit guys to add something for remembering errors).

I agree with your point about too much selecting and clicking, but I run
most of my failing tests via doits sitting in comments in the various
methods; I use the browser to verify that all is well or to discover
where to look for problems.

Re adding instance variables, there is probably a more direct way, but
you can create expressions and evaluate them.  You are welcome to use my
CodeGenerator package which provides a preview framework, or can be
scripted to slash and burn.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]