Better write a test or a comment for a given method? Was: Re: Two Squeak-related bugs and three questions

Markus Gaelli gaelli at emergent.de
Fri Jun 16 07:56:21 UTC 2006


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.

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

I currently don't see how these "new syntax elements" you propose  
would look like, and why they are needed. Are we in sync that we  
better store the relationship between tests and methods under test  
into the tests?
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



More information about the Squeak-dev mailing list