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
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
squeak-dev@lists.squeakfoundation.org