SUnit Testing merged with Examples for Methods

Ted Kaehler Ted at SqueakLand.org
Wed Dec 5 01:32:57 UTC 2001


Folks,
	Yes, I do agree with this:

At 10:17 PM -0500 11/30/01, Stephen Pair wrote:
>Most uses of Sunit that I've seen will have a TestCase class
>for a subsystem, not an individual class.  For example, with Kats, I
>have a suite of 45 tests in one class that exercises the classes and
>protocols designed for use by the users of Kats.  I don't usually
>directly test the classes and protocols that are internal to a package,
>those will get tested indirectly via the tests of the public interface
>of the package.

At 8:48 AM -0800 12/3/01, Ward Cunningham wrote:
>[snip]
>That is not to say that some language/environment innovation 
>couldn't change this statistic. I've had good luck with tables of 
>values interpreted by fixture code that is much smaller than the 
>typical SUnit equivalent.

	Scott Wallace has suggested a similar table driven way of 
generating the examples.  I think #exampleFor: is tolerable, and 
anyone could implement it to read a table.

	Perhaps the match-up of test cases and examples of methods
is not perfect.  TestCases tend to be testing large subsystems, and 
examples for users will start out with the simple 'beginner' methods. 
But some methods will be both need legitimate testing and be good for 
users to look at, such as String>>asNumber and 
Base64MimeConverter>>mimeEncode:.

4568ViaSUnit-tk.cs
4580ViaSUnit-2-tk.cs

I have added a second update that makes TestRunner show one entry per
class that has the MethodCall type of test.  Any class-object that responds to
#exampleFor: will be listed here.  The intention is to keep traditional
TestCases, and also the newer TestViaMethodCalls.  With this 
modification, the two ways of specifying test cases can live side by 
side.

I really appreciate everyone who wrote to me to educate me about SUnits.

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