Hi,

>In case this hasn't been clear to everyone, abstract test cases run all
>of their "sub-tests" if executed. 

Squeak now behaves like all the other Unit implementations (in other
Smalltalks and elsewhere). Abstract means there are no instances and
therefore no test cases to run. So I would expect it to behave like 
it is now - not to show or run abstract classes.

>In other words, in the 3.6 TestRunner >you can have a test structure 
>that looks like: [SNIP]
>and with AllMyTests being an abstract superclass you only need to select
>it and run all of my three tests at once.

We should use abstract test superclasses to implement common behavior 
and not to run the tests together. If we have what you describe there
is the danger that people change their systems design just to get 
the tests to run together.
So it's mainly the problem of using the simple standard TestRunner UI.

Personally I use the TestBrowser goodie which is really a nice
way to run and implement tests. It was created by Kazuki Minamitani-san
and I refactored it a little bit (the code is already
integrated).

See:
http://map1.squeakfoundation.org/sm/package/6dfad36f-afd0-40ec-b4aa-cd59445c4246
and 
http://kminami.fc2web.com/Squeak/Goodies/TestBrowser/index.html

If you have used it for a while I'm sure you will like it
and throw the simple TestRunner away. I use it in Sq3.6 up to Sq3.8 
images and it's rock solid !!! It's nice since you can run tests
by category, by class or run single test methods. Especially when 
you use Monticello and special class categories for tests this is 
a really helpfull and clearly arranged tool. 

I would vote for replacing the simple TestRunner with the TestBrowser
in the standard image and provide the old TestRunner as an
optional package. Later me want to convert it to use OmniBrowser
as it's base architecture.

Bye
Torsten

-- 
NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!