<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.28">
<TITLE>Re: Better write a test or a comment for a given method? Was: Re:Two Squeak-related bugs and three questions</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText44127 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Lets lighten up the topic a
bit, shall we? How about we all submit our nominations for
"most-useful-comment-i-have-seen" award of 2006, here's one from the
bowels of the transaction code in our db framework,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>"If you think this method is wrong, think
again"</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Pretty effective at keeping people away
when they tend to blame the framework for every issue they
can't understand, myself included ;)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV></DIV>
<DIV id=idSignature91741 dir=ltr>
<DIV><FONT face=Arial color=#000000
size=2>-Boris<BR><BR>--<BR>+1.604.689.0322<BR>DeepCove Labs Ltd.<BR>4th floor
595 Howe Street<BR>Vancouver, Canada V6C
2T5<BR><BR>boris@deepcovelabs.com<BR><BR>CONFIDENTIALITY NOTICE<BR><BR>This
email is intended only for the persons named in the message<BR>header. Unless
otherwise indicated, it contains information that is<BR>private and
confidential. If you have received it in error, please<BR>notify the sender and
delete the entire message including any<BR>attachments.<BR><BR>Thank
you.</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B>
squeak-dev-bounces@lists.squeakfoundation.org on behalf of Milan
Zimmermann<BR><B>Sent:</B> Thu 15/06/2006 10:43 PM<BR><B>To:</B>
squeak-dev@lists.squeakfoundation.org<BR><B>Subject:</B> Re: Better write a test
or a comment for a given method? Was: Re:Two Squeak-related bugs and three
questions<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>On 2006 June 15 15:20, Markus Gaelli wrote:<BR>> On Jun 15,
2006, at 8:50 PM, Milan Zimmermann wrote:<BR><BR>(actually it was Tim :)
)<BR><BR>> >> The old joke "comments? why<BR>> >> do think
it's called code?" sums up the antithesis of responsible<BR>> >>
programming that seems to be the normal approach. Yes, reading the<BR>>
>> code tells you what it *does* do (until you find a compiler bug
for<BR>> >> example) but it tells you nothing about what it was
intended to do,<BR>> >> what spec it was putatively meeting or what
limits on its<BR>> >> functionality were known about.<BR>><BR>>
So did tests, pre- / postconditions and counterexamples -- if they<BR>> were
known to focus on a given method.<BR>><BR>> If in doubt whether I should
write a comment or a test, I'd go for<BR>> the test.<BR>> Nice thing is,
that the test not only helps other developers to<BR>> understand the system,
but also the computer to automatically...test it.<BR><BR>I agree with what you
are saying with two comments.<BR><BR>
While tests are for asserting whether a method, instance, or module behave
as<BR>expected under given inputs (including whether the code under test
handles<BR>broken preconditions etc), I would say comments are necessary to
describe<BR>intent, purpose, broader "cultural" circumstances, design
decisions,<BR>including dead end streets encountered when the code (method,
instance,<BR>module) was designed and developed.<BR><BR>> If I had enough
time, I'd write both.><BR><BR> Yes,
but I would argue (this is my perception) that writing good comments<BR>takes
about 10% of the time of writing good comprehensive tests, so if there<BR>is
enough time writing good tests, there is always time to start with a<BR>helpful
comment describing intent and purpose (etc - as above). For that<BR>reason, I am
not sure in practice writing test first and documentation second<BR>is the best
approach, as writing a really "complete" test for a module or<BR>application may
be close in time to writing the module or application self,<BR>while writing
comments can give good guidance for future readers of the code,<BR>as well as
present or future writers of code tests.<BR><BR>> If there were a discussion
to introduce a "documentation space" shown<BR>> next to a given method to
document it (as it is the case for classes<BR>> right now) I'd strongly argue
to use it for tests -- and not for<BR>> comments.<BR><BR>I don't want to
argue with that (I think your assumption is if option was<BR>given to only have
one such space), but I would really miss my comments (of<BR>the type described
above), written to save my (and hopefully others')<BR>backside in the
future.<BR><BR>> You can find a suggestion for explicitly linking a test to a
method<BR>> here:<BR>> <A
href="http://www.iam.unibe.ch/~scg/Archive/Papers/">http://www.iam.unibe.ch/~scg/Archive/Papers/</A><BR>>
Gael04cLinkingMethodsAndTests.pdf<BR>><BR><BR>I think I read your article in
the past :) - rereading it I like it, if I<BR>understand, the meta model ties
one test method to each method, does it also<BR>play any role in defining the
test suites?<BR><BR>> Today I would either use method properties or blocks to
denote the<BR>> method under test (and not comments anymore...;-)<BR>> A
better example than testing an accessor (as used in the screenshot<BR>> of
above paper - boooring) would help also to illustrate the power of<BR>> a
five-pane browser, where the fifth pane included tests.<BR><BR>yes<BR><BR>>
Note that we could also easily extract the concrete types for the<BR>> method
under test - and - if we returned the result of a sampled<BR>> method, also
the instance variables of the class of the resulting<BR>> object.<BR><BR>So
if developer writes tests first, he/she defines the argument types and<BR>return
types that are passed to and returned from the tested methods, and the<BR>types
then can be extracted from the tests by tools, making type
declaration<BR>unneeded, is that what you are saying, or am I
misunderstanding..<BR><BR>Thanks Milan<BR><BR><BR>><BR>>
Cheers,<BR>><BR>> Markus<BR><BR></FONT></P></DIV>
</BODY>
</HTML>