Keith,
Running tests from the browser is a fine idea. Can a test case be a member of more than one suite in your approach? I suspect that most of the time, I run more tests than I really need to run, which is fine to a point. Early in trying to fix something, I will lock in on one test and #prod: that until it passes anyway, so there is little harm in snaring some extra tests. With that said, some bugs work down to a struggle among some stubborn test methods (e.g. any three will pass but not all of them), at which point it is nice to be able to tweak the set that runs.
I got started doing this kind of testing in part because Dolphin's sunit browser did not handle selections as well as I wanted. It would run selected tests, but the selection would get clobbered with the resets, and (my fault I realize) it was too easy to run all vs. running the selected methods. It started as a compromise, but I quickly grew to like using the browser for getting the big picture and then using doits to drive debugging of failing tests. I _think_ the runner I see in Squeak does a good job of selection handling, but I have not used it enough to give a good judgement.
Bill
Keith Hodges: 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
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
Dear Bill,
you ask whether a test can be in more than one suite, absolutely.
First of all classes explicitly define and publish their own suites.
You could have:
#allStandardTests defined as all methods matching 'include:test*' #testsBeingWorkedOn defined as methods in method category 'include@wip'
thus some tests may be members of both groups.
I shall append the relevant information from the class description for you
Keith
------------------ More flexible suite building API:
Asking an abstract class for #suite: will build the entire suite for all of its concrete subclasses. Asking a concrete class for #suite: will just return the suite for that one class.
Suites are defined as class methods for a testcase class. example:
MyTestCase>>myTestSuite "all 'test*' methods, but not those in category 'long tests', or tests flagged with #BrokenTest" ^ #( 'include:test*' 'exclude@long tests' 'exclude#BrokenTest' )
Suites are obtained via either a) a selector which references a defined suite or b) an explicit string defining a match c) an array of a & b.
TestCase suite: #myTestSuite. TestCase suite: 'include:test*'. TestCase suite: #( 'include:test*' 'include:longtest*').
The array can be used to combine other suites example: myTestSuiteWithLongTests ^ #( #myTestSuite 'include@long tests' )
Published Suites API
#publishedSuites provides a list of test suites published by each TestCase class that can be picked in the TestRunner. This provides a natural UI for selecting from a range of testing scenarios. e.g. tests for different products, releases, platforms, performance monitoring tests, long tests, tests needing additional services (db)
Published Filters API
#published filters provides a list of filters that can be picked in the TestRunner. This provides a natural UI for including/excluding groups of tests from a suite.
publishedFilters ^#( #filterOutBrokenTests )
filterOutBrokenTests ^ 'exclude#BrokenTest'
___________________________________________________________ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
squeak-dev@lists.squeakfoundation.org