--- In squeak at yahoogroups.com, "Lukas Renggli" <renggli at ...> wrote:
>
> > > 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.
> 

I think that Diego is saying that it is better not to test the
implementation but the behavior of an object. If the implementation
changes and you have implementation tests, you will have to change
them. On the other hand, if you only test behavior and you change the
implementation you should not change the tests.
I understand that you would want to see that your implementation is
right, but is not enough to test the behavior? what implementation
mistake couldn't you find testing the behavior?
If there is an implementation error, for sure it will pop up in a
behavior test. If not, I beleive that you are not covering a 100 % of
your code.
Here at Mercap, we have more than 7000 unit tests and we do not test
implementation at all and when we found a bug, it was because there
were not "behavior" test to cover that situation.

> >  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.
> 

We have talked with Diego many times about annotations and our opinion
is that annotations are a tool that do not follow the idea of having
only "objects and messages". It is sintax sugar that makes the
language more difficult to use. It is a matter of taste and I don't
like sugar :-)... (For sure you have discuss this on the list many
times...)
I haven't read the hole track, but I understand the first question of
the track was, in essence, how to categorize tests. We did have the
same problem here and we created different test suites. So we have a
test suite for the unit tests, we have a test suite for functional
test (they take more time), we have a test suite for those objects we
call "systems", we have a test suite to check coverage and SmallLint
compliance and we have a test suite for architecture issues (it is
important when you work with Envy and GemStone). 
So, we run each test at different stages of the development process.
For example, we run the unit tests all the time, but we run the
architecture test during the integration phase, before versioning. We
run the coverage and SmallLint compliance test before integration and
during integration, etc.
Anyway, we like the idea of keeping things simple and try to solve all
the problems with objects and messages, no more.... I'm not saying you
don't, but annotations, for us, looks "outside" that idea... I guess
time will show if they are a good idea or not, we may be wrong.

Hernan

> Cheers,
> Lukas
> 
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>