SUnit: Skipping tests?
renggli at gmail.com
Wed Mar 29 07:06:44 UTC 2006
> > 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.
> 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".
- 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.
More information about the Squeak-dev