Bill Schwab wrote:

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.

On my last big project, I had 500 tests for each simulation. With 3 or 4 subsequent versions of the simulation. The versioning of the tests were easily implemented by subclassing with modified tests for modified behaviour.

Not only that but it was extremely common for one test to invoke another, the first test might log the user in, the second might log the user in and change the configuration, the third might login and trigger an alarm test.. etc. following a decision tree as to what a user might do with the system.

I dont see why tests should be independant of one another? It may be an ideal, but I guess it depends upon what it is you are testing exactly. I think that there are scenarios, such as tracing a deep decision tree, where it is a good idea for tests to be dependant upon each other, even just for pragmatic reasons.

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

___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html