SUnit Testing merged with Examples for Methods
Ted Kaehler
Ted at SqueakLand.org
Fri Nov 30 19:32:13 UTC 2001
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
More information about the Squeak-dev
mailing list
|