At 02:37 PM 1/23/2002, you wrote:
>on 23/01/02 7:06 PM, Withers, Robert at rwithers at quallaby.com wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: ducasse [mailto:ducasse at iam.unibe.ch]
> >>
> >>>
> >>> This need for effective review is also why I felt it
> >> important to have SUnit
> >>> supported in the BC image.  (changeset posted yesterday).
> >> We should be able
> >>> to produce 20-30 tests for BlockClosures, themselves, and
> >> 50+ for generators
> >>> nad tools that use blocks, like the Compiler, the
> >> CCodeGenerator, the
> >>> Inspector, and the debugger.
> >>
> >> I'm not good enough nor have the time to help in that task
> >> but this REALLY
> >> important. Having tests will really help. So please please push that.
> >>
> >
> > Well I don't like being pushy, but I will try to take a little initiative.
> > :)  I think it is a nice opportunity to learn about the TestViaMethodCall
> > mechanism, at least for some core tests.
> >
> > Speaking of testing, the SDDB, that Duane just implemented, would be great
> > for storing Tests alongside the documentation of classes.  This way we 
> don't
> > have to pay for them to sit in the image.  We could create a 
> TestCaseLoader,
> > which would load, run, then unload the TestCases.
> >
>
>Hi rob

Hi Stef

>The problem with the test as done in the exampleFor: method is that there do
>not really represent one single scenario.

yes, it is a set of simple scenarios.  I don't find this to be a problem as 
long as you scope them correctly.  Core language features, which test 
without extensive fixtures and have just a single state test seem to be the 
correct scope of exampleFor:.  They could also represent more than a test, 
but actual content for a lesson.

>Iwwrote a lot of Sunit change and I like the fact that every test tells me a
>little story. The exampleFor: approach is non incremental I cannot remove on

I agree with this too.   I like to have a real TestCase, when, 
heuristically: 1) The testee is not a standard core class.  2) there are 
several fixtures required to test a scenario.  3) there are multiple 
assertions that I would like to make about the test scenario.  I think 
BlockClosures probably have both test scenarios.

>test, for that I have to edit and recompile the method. So I'm really in
>favor of SUnit tests or the exampleFor: method should be split in several
>little methods.

I suppose that that is possible to do, but why bother.  If you can bang out 
10 quick tests, that check function in normal ranges and boundary 
conditions, then that's perfect for exampleFor:  I would like to be able to 
specify exception tests for various behaviors as well.  Given the 
exceptional boundaries, as well, this could turn into documentation for 
interface types and semantics with examples.  If we go this far, then I 
would image a separate method for each interface, with a set of tests for 
each interface.  Finally, a test writer tool could display all tests for a 
given protocol and you could edit them and save them.  it would compile 
quickly behind the tool (in the one method).

So they don't bother me much, and I see more promise in the direction they 
are going.   Have you tried the HierarchicalTestRunner, yet?  It 
hierarchicalizes the exampleFor: methods under the TestViaMethodCall 
TestCase.  It would be neat to extend that to display the actual 
inheritance hierarchy of the Example Classes.


Rob