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
|