> > OrderedCollection>>beginOfTest
> >     <begin>
> >     self add: 1; add: 2
> >
> > Point>>test
> >     <test>
> >     self assert: lastIndex - firstIndex  = 1.
> >     self assert: (array includes: 1).
> >     self assert: (array includes: 2).
> >     ...
>
>  For me isn't a good idea to do "white box" testing. In the
> OrderedCollection example given, I don't care how the items are handled in
> the collection object, and I couldn't find any good reason to make a test
> like that. Because if I do a re factoring, maybe I have to modify all the
> tests written in that way :(

- If you rename #add: to #addItem: you have to re-factor your tests as well.

- If you have something more complex such as an AVL-, B-, R-Tree, etc.
you certainly want to test some internal state, simply iterating over
the elements cannot reveal all bugs. I don't see a reason why the
internal state of OrderedCollection shouldn't be testable as well.

>  But I don't like the idea of having "annotations"... I hate them :P

There are some problem in software engineering (mainly related to
extending) that cannot be cleanly solved otherwise.

> Because
> an annotation for me is like an "attribute", it's only data without
> behavior, but in the system is necessary to take decisions based on this
> "attribute value".

Wrong.

- No need to take decisions, the trick is to dispatch annotations onto
objects that understand these messages.

- Annotated method do have behavior, see Tweak that is using
annotations to define event-handlers.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch