Ralph,

I agree that simpler is often better, which is precisely why many of my
(Dolphin) tests are not simple, in the sense that they use helper
methods, many of which appear to belong in the TestCase hierarchy.  If I
were to follow your suggestion, I would have to duplicate those methods
to get the tests to run at all.

Dolphin's SUnitBrowser is a great tool, but I don't use it very often. 
It is great for figuring out whether all is well, or for finding failing
tests.  For work on a given failing test or group of tests, I use doits.
 Most of my methods have a comment that looks something like

    ThisOrThatTestCase prod:#testSomething.

#prod: arranges for setup and teardown, and either goes straight to a
walkback on error/halt, or does _nothing_ if all is well.  Such comments
frequently find there way into domain classes, so it becomes easy to
restart a failing test.  Finally, I have TestCase
class>>runTestsReferencing: allowing scripts such as

  TestCase runTestsReferencing:#toddsBug.
  TestCase runTestsReferencing:#realizeGizmo:using:.
  ...

where #toddsBug is a symbol strewn throughout the code for my cash cow.
 Todd reported it, so it was only fair to immortalize him. 
#realizeGizmo:using: is ficticious, there are several like-named methods
that I test along with Todd's bug.  I fixed it a couple of years ago,
but still find the tests useful to ensure that it stays fixed.

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




Ralph Johnson:
> Finally, breaking things up physically, rather than tagging things
> 'mentally' so to speak ruins any kind of smooth workflow. Write test
fix
> test, becomes write test in one place, when it works move it to
another
> place, debug it again in the new context.

I have done this for a long time.  Putting nonworking tests into
separate classes and packages is in fact perfectly fine.  My
experience is that your arguments are wrong.

Moving code around in Smalltalk is very easy.  It is almost as easy to
move a method from one class to another as it is to press a button.
It takes MUCH longer to figure out whether you want to move it.  Tests
should be independent of each other, so moving it should make no
difference to debugging.



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