On Fri, 16 Jun 2006 09:56:21 +0200, Markus Gaelli wrote:
> On Jun 16, 2006, at 9:15 AM, Klaus D. Witzel wrote:
>> On Thu, 15 Jun 2006 21:20:45 +0200, Markus Gaelli wrote:
>>
>>> 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.
>>
>> +1
>>
>> One could even go further and design new syntax elements (vs.  
>> properties unknown to the compiler) for attaching tests to methods, so  
>> reflecting the importance of tests.
>>
>> In a not so distant future, perhaps, the compiler would only accept  
>> code if all the tests which are attached to the input pass (this  
>> scenario would include the case where a method change makes a test  
>> fail) who knows :)
>
> Before SUnit developers either used comments or ad-hoc class side  
> methods to test or exemplify code.
> Comments had the advantage to be close to the method under test, class  
> side methods reflected the factory character of tests/examples, so that  
> they could be composed and SUnit made the tests collectable.
>
> My suggestion is to use class-side methods, which
> - denote their method under test using blocks (self test: [aReceiver  
> foo: aParameter]) or method properties
> - which are collectable as they are in a special method category (using  
> the same trick as monticello)
> - and which return the object of interest they created, so that tests  
> can be composed.

Yes, that was (implicitly) among my intentions, for example (not to be  
taken literally) for a method like
isBinarySelector
  ...implementation...
  '(tested isKeywordSelector and: [testing isBinarySelector]) not'

in which the first test supplies the shared "material" for the second one,  
for composition, like in http://en.wikipedia.org/wiki/Relevance_logic  
under "The fundamental novelty in relevance logic is ..."

> A decent test tool including instrumentation would not only know the  
> tests which "focus" on a given method but also all tests/examples, which  
> execute a given method along their way.
> Saving a method should rerun all the tests which execute it, no matter  
> if they focus on it or not.

Agreed, that's what I said.

> Having a nice tool like spoon, one could think about an agressive mode,  
> where methods are only storable, if there is some automatic  
> tests/examples to imprint them.

Yes, a natural extension to what in the above the compiler does to methods.

> I currently don't see how these "new syntax elements" you propose would  
> look like, and why they are needed.

I have nontrivial OO examples written in a non-Smalltalk syntax (no, not  
c-ish ;-) which I can be make available on my web server, if that is  
interesting. Besides of that, I could have remarked earlier that the form  
of a syntax extension doesn't matter to me, as long as it is "acceptable"  
and fulfills the mission.

> Are we in sync that we better store the relationship between tests and  
> methods under test into the tests?

Sure, np: with my suggestion you can easily extract tests out of methods  
(e.g. their parse nodes) and with your suggestion I can easily associate  
tests with their compiled methods - either way suffices.

/Klaus

> Above "self test: [aReceiver foo: aParameter]" idiom can be easily  
> implemented as
> Object >> test: aBlock
> 	^aBlock value
> and then easily parsed again. One advantage of using this idiom is that  
> you stay dialect agnostic.
>
> Cheers,
>
> Markus
>
>