Hi Markus,

On 2006 June 16 03:25, Markus Gaelli wrote:
> Hi Milan,
>
> 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...

I think what you are saying (and I agree) that things such as "class 
comments", "method comments", and also "class tests" "method tests" should be 
represented by objects in the framework (associated to their owner classes)

It seems that whether comments are presented to the user "inside the 
text" (and extracted from there by the IDE, for example first comment in 
method becomes the method comment), or presented in a separate pane is 
probably an implementation detail. Tests should likely be in a separate 
pane.... I do not know Squeak core that well, but from a search I just did it 
seems that "class comments" are represented by "Comments" by cannot find any 
member variable or object representing "method comments". But in any case, to 
get back to tests, it does make lots of sense to associate tests in Squeak 
framework to the elements (classes, methods) they test.

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

yes

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

that makes lots of sense ...

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

sounds good, thanks for commenting on this. In a really disciplined 
tests-first environment I see how this would make any need for type 
declaration go away, although only for the developer, not for the test 
writer, and it seems in practice such test-type-extraction tool combined with 
other tools that infere types could be very useful.

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

I am playing with it - Let's say I go to Bank class>> code: method. I see 2 
test in the right pane ... but I cannot figure out how to run them, but am 
tired, will try again tomorrow.

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

yes - and thanks for your comments and image

Later Milan


>
> > Thanks Milan
>
> Thanks for commenting,
>
> Cheers,
>
> Markus