I read a few Pharo posts lately about long tests. In this regard allow me to describe briefly some code I am now writing. I will eventually release this code to SqueakSource and, if the Pharo group is interested, I will port it to run on Pharo as well. I use long tests a lot in development. These tests are not really suitable as SUnit tests because they are too slow and some of them are parameterizable. These tests are meant for finding bugs during development; less so for verifying code still works before a release. However, I decided to use the SUnit idea and code to enhance running these tests. First, I refactored TestCase by giving is a superclass and moving all the TestCase code into its superclass. I then created a class RunnCase which has the same parent class as TestCase. The reason for refactoring TestCase this way is so that if TestRunner is run the classes under RunnCase DO NOT SHOW UP. I now put my long tests into RunnCase subclasses. Note that I believe that TestCase should be so refactored even if you are not interested in using the tools I am building because it allows others to build their own tools just as I am doing. I then subclassed TestRunner with subclass TestPlusRunner. TestPlusRunner allows running the same tests as TestRunner. TestPlusRunner is like TestRunner with a few minor changes including: 1) an extra window that displays individual test case methods when only one class is selected. Subsets of test cases from an single class can be selected and run. 2) (Ignore this paragraph is you like) it has as some additional buttons. Currently the buttons are there but not the functionality. The intent of the buttons is to be able distribute the running of a set of tests over a number of computers and return to one computer only the tests that failed so they can be debugged. Specifically, the intent is to be able to file out a set of tests, send them to another user/computer, have that user/computer run those tests and send back a file containing all the tests that fail, and then be able to load the failed test and debug them. I then subclassed TestPlusRunner with subclass RunnRunner. RunnRunner runs tests of subclasses of RunnTest. RunnRunner is like TestPlusRunner with the ability to set parameters that can affect the running of tests. Currently the only parameter that can be set are a list of size values. For example, if this parameter is set to '3-5,7,9-12' then the tests that are run will be given this parameter and then use this parameter however they want but presumably either ignore it or run the test once with each of the size values: 3,4,5,7,9,10,11,12. Several other parameters are also planned: 1) seed. The seed is a value with which to initialize a random number generator that the tests can optionally use in the generation of test data for the tests. 2) number of subtests. A test may have the ability to generate and run a number of subtests (probably using 1)). This parameters indicates how many subtests to run. 3) subtest start. If a test runs 1000 subtests and then detects a failure then the user may not want to rerun the first 999 subtests before running subtest 1000 again. This parameter allow the subtests to be run starting at subtest #1000. Feedback on this work is most welcome either positive or negative (but constructive). Regardless of opinions, it would be great if the refactoring of TestCase described above were done. It is the way it should have been written in the first place. Note that some additional minor refactoring of TestCase and TestRunner is required. Email me if you want details. Regards, Ralph Boland