Hi Guys,

I have been travelling so this will try to fold some of the responses into a 
single comprehensive reply:

[Torsten Bergman proposed to use TestBrowser]
> 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 !!!

I tried it and I couldn't get it to show my test category unless I switched 
to "show all" (this might be a bug in the filtering). Besides that it has 
the clear advantage that it actually works (yay!) but personally, I would 
really prefer the simpler UI of test runner (sigh).

[Romain Robbes lobbied for BrowseUnit]
> If all your tests are in a single package (a PackageInfo instance),
> you could use BrowseUnit to run them at once.

I installed this too but I couldn't find out how to make BrowseUnit work. It 
didn't add any buttons to the browser (although the docs claimed it would) 
there wasn't anything in menus so it's really unclear to me how to use it. I 
might give this another try when I figure out what went wrong.

[Marcus on showing abstract tests]
> I was 100% sure that the idea of an abstract testcase was that they are 
> supposed to be abstract classes. (Do not show up in Testrunner, test
> are inherited by the children). I never had the idea to use them for 
> grouping tests... so with that mental model, I added the fixes that 
> removed the abstract tests from the testrunner that were postet to the
> list.

This is in clear contradiction to the code which can be found in, e.g., 
TestCase class>>buildSuite which specifically builds a test suite of all the 
sub tests if invoked on an "abstract" superclass[*]. So the intent here is 
obviously that it's perfectly okay to "run abstract test cases".

[*] I mean, c'mon guys - how do you run all of Squeak's tests 
programmatically at once? The way I do it is simply executing "TestCase 
buildSuite run" and off you go. What do you do?

> (Having Abstract classes in the TestRunner has the problem that "run  all" 
> then runs tests multiple times).

[... and later we have Colin argueing about essentially the same issue...]

> The problem with the old behavior is that it *also* causes you to have  to 
> select each and every test manually. You can't just use the 'Filter' 
> button to select some tests and run them all, because the abstract 
> classes will cause tests to get run twice -  or more than twice if you 
> have several levels of abstract classes in your test hierarchy. This 
> makes moderately-long-running test suites take much longer.

I might not have been clear on this issue - it is the whole idea (!) that 
you run these tests "multiple times". Consider the following situation: Let 
us assume we have a set of invariants for a class which must hold true for 
all subclasses. Such as "when the mouse moves over [any subclass of] button 
its state changes from normal to over". Yes, we can rely on copying the test 
for each and every subclass of Button. Or, alternatively, we put it in the 
superclass (abstract or not) with the specific intent that this test is an 
invariant for the (abstract or not) class and all of its subclasses. So that 
if you make a new button subclass these invariants can be automatically 
validated without you much doing about it.

Also, it is likely that situations in which this is relevant (lots of tests 
which should be grouped together) will expose some common behavior which is 
best put into a common superclass.

[Bert mentioned, regarding the same]
> Wouldn't it be trivial to avoid these duplicate tests? Like if you only 
> collect test methods from the class that actually implements them? Am I 
> missing something obvious?

No, that's quite right. There are various other ways in which the UI could 
make it much simpler to specify individual tests and groups (and assemble 
the "right" set of tests to be run). And really, all I'm asking for is ONE 
solution - and the last one available was taken away with the latest changes 
:-(

[Markus replied]
> But there are testsuites that use Abstract Tests in the sense of abstract 
> classes: e.g. the ClassTestCase implements a bunch of tests
> that should be run on all tests that are subclasses of ClassTestCase.

And there is absolutely no problem with this. If ClassTestCase is abstract 
then (to repeat) "ClassTestCase buildSuite" will do The Right Thing and 
that's precisely what I am asking for.

[Finally, Goran noted]
> I am all with you Marcus, even though I am no super SUnit expert it
> seems to me that suites should be used for grouping. As always, object
> composition seems more appropriate than inheritance.

And again, all I can point to is TestCass class>>buildSuite which does 
precisely what I am asking for, no more, no less. It seems that the 
author(s) of SUnit and I are in agreement about "good behavior" here and all 
I am asking for is a UI which makes that behavior accessible.

Cheers,
  - Andreas