Hi Milan,

>
>> If there were a discussion to introduce a "documentation space" shown
>> next to a given method to document it (as it is the case for classes
>> right now) I'd strongly argue to use it for tests -- and not for
>> comments.
>
> I don't want to argue with that (I think your assumption is if  
> option was
> given to only have one such space), but I would really miss my  
> comments (of
> the type described above), written to save my (and hopefully others')
> backside in the future.

This discussion about a "documentation space" for methods is purely  
hypothetical of course, as the concept of method comments is already  
built in the language and I guess nobody - including me - would  
understand the value of tearing out comments from methods into a  
separate pane. I just mentioned it to illustrate the problem, that  
method tests are not built in yet whether in the language/ meta model  
of smalltalk nor in the GUI - but we could, as we built in comments  
for classes onto a prominent place into the GUI recently...

>
>> You can find a suggestion for explicitly linking a test to a method
>> here:
>> http://www.iam.unibe.ch/~scg/Archive/Papers/
>> Gael04cLinkingMethodsAndTests.pdf
>>
>
> I think I read your article in the past :) - rereading it I like it,

:-)

> if I understand, the meta model ties one test method to each method,

0...n method commands to each method, yes. A method command could be  
also an example, or a counter example.

> does it also
> play any role in defining the test suites?

The part of the meta model described in this paper does not mention  
suites. But the concept of suites is certainly a good one and the  
complete meta model reflects it.
Note that we have the classic suites of independent tests like in  
SUnit. Denoting a test belonging to such a suite could be either done  
technically again by method properties (so the tests knows to which  
suites it belongs to) or by the approach of SUnit, where testsuites  
can be built to include several tests.

But I like to think about many tests also as "cascaded test suites"  
meaning that many long test methods could be broken down and composed  
out of several (one-)method commands. Not that I am saying, we should  
refactor the existing ones, as this does not bring much, but when  
writing new ones, one could consider to write smaller one-method  
tests, which return the "interesting object" they created or  
manipulated, so other tests could be written on top. The advantages:  
smaller test methods should mean better readability in general, more  
reuse of complex test scenarios, faster tests, and concrete types  
that method commands provide.

>
>> Note that we could also easily extract the concrete types for the
>> method under test - and - if we returned the result of a sampled
>> method, also the instance variables of the class of the resulting
>> object.
>
> So if developer writes tests first, he/she defines the argument  
> types and
> return types that are passed to and returned from the tested  
> methods, and the
> types then can be extracted from the tests by tools, making type  
> declaration
> unneeded, is that what you are saying, or am I misunderstanding..

The developers write which concrete objects are used to test the method.
Using some coverage tool an intelligent test tool can easily store  
the classes of the parameters _and_ result used by a given method  
under test - and display this to the developers, yes.

I prepared an image used for that oopsla workshop on:
http://www.iam.unibe.ch/~gaelli/oneMethodCommandsRDL.image.gz

I display some "concrete examples" there using some bubble help as  
seen on a screenshot here:
http://www.iam.unibe.ch/~gaelli/rdlScreenshot.png

Could be the types certainly also....

> Thanks Milan

Thanks for commenting,

Cheers,

Markus