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