Block Closures are here!
rwithers12 at mediaone.net
Thu Jan 24 01:36:05 UTC 2002
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
> > have to pay for them to sit in the image. We could create a
> > which would load, run, then unload the TestCases.
>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
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.
More information about the Squeak-dev