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
Thu Jun 15 19:20:45 UTC 2006


On Jun 15, 2006, at 8:50 PM, Milan Zimmermann wrote:

>
>> The old joke "comments? why
>> do think it's called code?" sums up the antithesis of responsible
>> programming that seems to be the normal approach. Yes, reading the
>> code tells you what it *does* do (until you find a compiler bug for
>> example) but it tells you nothing about what it was intended to do,
>> what spec it was putatively meeting or what limits on its
>> functionality were known about.

So did tests, pre- / postconditions and counterexamples -- if they  
were known to focus on a given method.

If in doubt whether I should write a comment or a test, I'd go for  
the test.
Nice thing is, that the test not only helps other developers to  
understand the system, but also the computer to automatically...test it.
If I had enough time, I'd write both.

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.
You can find a suggestion for explicitly linking a test to a method  
here:
http://www.iam.unibe.ch/~scg/Archive/Papers/ 
Gael04cLinkingMethodsAndTests.pdf

Today I would either use method properties or blocks to denote the  
method under test (and not comments anymore...;-)
A better example than testing an accessor (as used in the screenshot  
of above paper - boooring) would help also to illustrate the power of  
a five-pane browser, where the fifth pane included tests.
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.

Cheers,

Markus




More information about the Squeak-dev mailing list