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@anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029