Can't find a reference, but urban legend says that the Great Beck said that SUnit was something that should be so simple you could write it on the train (meaning on a commute). The simplicity and versatility of SUnit means there's lots of ways to use it. I don't think there is any one right way to use it. You use it in the way that works best for you. One example of this is whether you choose to associate TestCases 1:1 with classes. Some do religously. Some write great big acceptance tests. Some write a TestCase per unit of functionality (a good example of this one is the AnnouncementTests).

It's fun to introspect on one's TestCases and then imagine how we might abuse the statistics we fetch from some queries. Here's a query similiar to the last post:

| func |
func := [:class | | nonAPICount ratio |
  nonAPICount := (class selectors reject: [:each |
    each = #setUp or: [each = #tearDown or: ['test*' match: each]]]) size.
  ratio := nonAPICount / class selectors size.
  (ratio / 0.1) ceiling * 0.1].
(SUnit.TestCase allSubclasses reject: #isAbstract) groupedBy: func

What's this do for us? First of all it puts the evaluator in a block, so that we can do different things with the function. This is a common thing I'll do when prototyping in workspaces. f(x) is... And then do stuff around however I've defined f(x). The f(x) in this case is to compute how many of TestCase's methods are core API methods. That is, testMethods (and the setUp/tearDown). The last little bit of the block, is a "round up to" expression.

There's no table to show here. What I found was that I have a good many tests at 0.0. And some at 0.1 (66% for the two). And less going up. Which is what I tend to prefer. In the same vein as "any method that won't fit in the code pane is probably to big", I tend to push back against TestCase classes having much more than just tests (and not becoming programs in and of themselves).