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