Keith,

Running tests from the browser is a fine idea.  Can a test case be a
member of more than one suite in your approach?  I suspect that most of
the time, I run more tests than I really need to run, which is fine to a
point.  Early in trying to fix something, I will lock in on one test and
#prod: that until it passes anyway, so there is little harm in snaring
some extra tests.  With that said, some bugs work down to a struggle
among some stubborn test methods (e.g. any three will pass but not all
of them), at which point it is nice to be able to tweak the set that
runs.

I got started doing this kind of testing in part because Dolphin's
sunit browser did not handle selections as well as I wanted.  It would
run selected tests, but the selection would get clobbered with the
resets, and (my fault I realize) it was too easy to run all vs. running
the selected methods.  It started as a compromise, but I quickly grew to
like using the browser for getting the big picture and then using doits
to drive debugging of failing tests.  I _think_ the runner I see in
Squeak does a good job of selection handling, but I have not used it
enough to give a good judgement.

Bill



Keith Hodges:
With so much in the class hierarchy, including extra functionality such

as time-outs in my TestCasePlus class moving an arbitrary test out to 
another class just would not work. Tests are rarely just isolated
items. 
Of course you can argue that they should be, but that's not the way it

goes in practice for me at least.

>  Most of my methods have a comment that looks something like
>
>     ThisOrThatTestCase prod:#testSomething.
>   
I did that too. Wouldn't it be good if the browser new how to invoke a

test with a button.

> class>>runTestsReferencing: allowing scripts such as
>
>   TestCase runTestsReferencing:#toddsBug.
>   TestCase runTestsReferencing:#realizeGizmo:using:.
>   
I settled for having TestCases explicitly declare membership in a test

suite, then being able to run a suite.

TestCase suite: #tl1Version1Suite
> where #toddsBug is a symbol strewn throughout the code for my cash
cow.
>  Todd reported it, so it was only fair to immortalize him.
>   
I simply used 'kph todo' and 'kph mod' etc etc strewn through out my
code.
> I am confident that you could adapt or extend this idea to give you
the
> flexibilty you seek while leaving the test case heirarchy,
packaging,
> etc. in tact.
>
> Bill
>   
The TestRunner improvements that I table, allow definition of suites
by.

a) method name match
b) method category match
c) method source containing literal symbol or flag.

so we got your ideas covered. (Just need to add pragmas!)

best regards

Keith




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bills at anest4.anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029