+1!

I think the block constructs can be used in may cases to achieve the  
same goal as annotions.
Looking at all the should: and shouldnt: construct can give you an idea.

The nice thing is that you can browse for them using your standard  
"browse senders".
I, for example, want to denotate the "unit under test" of the unit  
test, which turns out to be a method in most of the cases.

For achieving this goal, one just can bracket the method under test,  
with a
	self test: [someMethod]
construct.

This also gives nice backwards and sidewards compatibility to Squeak  
and other dialects.
As long as Smalltalk already provides me with some means to achieve a  
goal in a simple way, I am all for exploiting that before introducing  
another concept.

Looking at tweak (and being a great fan of Etoys) I like the idea to  
denotate some event, when a method gets triggered, though debugging  
such an event based system might be hard.
I haven't thought about using the block idiom described above for  
achieving this goal, so I don't know if that would be possible also,  
but my feeling tells me that it should be the case.

Cheers,

Markus

On Mar 29, 2006, at 2:38 PM, hernan_wilkinson wrote:

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