Folks,
	SUnits are a style of testing that verify the operation of a 
list of specific methods.  The structure for SUnits has been in 
Squeak for a while, but only forty (40) out of 44,000 methods 
actually have a validating test.    I have embarked on a radical 
program to improve that.  Here is how I have changed things:

[ ] To test a method, you needs to make up a receiver, arguments, and 
a known answer.  Scott Wallace is introducing an "Instance Browser" 
to Squeak that shows you an example receiver and arguments for each 
method.  It lets you run the example.  But, where are we going to get 
the example receivers and arguments for a method shown in an Instance 
Browser?  They can be the same as for a test of the method.  I have 
written code that generates objects that can be used for *either* an 
SUnit test, or an example method call.

[ ] Another thing that should be associated with each method is some 
"type information".  This is the protocol that each argument object 
needs to respond to.  The same mechanism that produces a test case 
can store this info also.

[ ] In classic SUnits, there is a separate 'testing class' for each 
class in Squeak.  This would double the number of classes, and is too 
much overhead.  I have created a new subclass of TestCase that owns a 
Verifier.  Verifier is a subclass MessageSend that holds the answer 
that the method is supposed to produce.

Object #()
     MessageSend #('receiver' 'selector' 'arguments')
         MethodCall #('lastValue' 'methodInterface' 'timeStamp')
             Verifier #('desiredAnswer' 'passed')
                  VerifierOfProperty #('theTest')

I have made a subclass of TestCase that holds a Verifier.  A 
TestSuite of these behaves like a normal test suite, and does not do 
too much violence to the careful design of SUnits.

[ ] A Verifier can only test (a) whether a method returns the correct 
value and (b) whether it gets an error while running.  A 
VerifierOfProperty tests for a specific state change after a method 
has run.  Classic SUnits allow other kinds of assertions and tests. 
Except for verifying that a method produces a certain kind of error 
in a certain case, a series of VerifierOfProperty can test everything 
that a classic TestCase can.

[ ] To collect the test cases, I simply enumerate the implementors of 
#exampleFor:, and call each one with 'all'.  That returns a list of 
Verifiers, which are run as test cases.

[ ] The SUnit code comes with a TestRunner user interface.  Say
      TestRunner open
and click on Run All.  After you have my update, the TestCase  called 
TestViaMethodCall collects and runs all tests that are created with 
#exampleFor:.  (One drawback is that when a method has more than one 
test, the individual subtests are not named.  We could give them 
names in the future.)

These changes will be in the next batch of external updates.  If you 
can't wait, ask me for the file now.  I invite you to supply an 
example for any method by implementing #exampleFor: in some class.

(In the future, we'd like to have the kind of TestCases that SUnit 
has now, but not have the overhead of doubling the number of classes. 
One way to do this is to make Metaclass do everything that TestCase 
does.  The individual testing methods would begin with a standard 
prefix like 'textSU'.  Any class that has a method whose name begins 
with 'textSU' would be found by TestRunner, and entered into its 
list.  Any comments on this?)

--Ted.
-- 
Ted Kaehler         http://www.squeakland.org/~ted/
When we were young, we were told that "everybody else is doing it" 
was a really stupid reason to do something.  Now it's the standard 
reason for picking a particular software package. -- Barry Gehm