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