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.