This is great. I'm eager to play with it.
I was afraid that the Squeak community would miss one of the really
important values spread by XP: testing. So tool support was missing but with
your changes we will be able to push test a step further.

Thanks for that!



on 11/30/01 8:32 PM, Ted Kaehler at Ted at SqueakLand.org wrote:

> 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.