Hi all

I participated at the SmallNic (Smalltalk picnic) at Berne today. We
were 
14 participants. It was generally meant to be for all Smalltalk dialects
but had a strong Squeak slant.

Marcus Denker from the German Squeak Users group came up from 
Karlsruhe. The Squeak 3.2 CDROM they have done is a helpful tool for the
Squeak 
community. It contains among other things a snapshot of the minnow swiki
and 
the complete mailing list archive. 

We first had  some short demonstrations (among them SmaCC).
Then we split into various groups doing different things.

Stephane Ducasse, Alain Fischer and I wrote a unit test for Morphic (the
code
is in another thread).

I have known for quite some time about the SUnit framework
but practically I didn't use it.
I did most of my testing just in Workspaces, which I kept.

The discussion of this week motivated me to do write 10 tests yesterday.

Today Stephane, Joseph and Diego pointed me at some additional issues. 

Stephane was able to convince me that unit tests may really be
a substantial part of a good documentation. 
Before I was thinking of unit tests only as something additional to 
do to write a very robust application (checking for boundary conditions
and things like that) . It is true that unit tests are good for that as
well.
 
I suggest that we try out using unit test as documentation 
in the next few weeks and see how it works. That includes sending
them as change set attachments to this list and ask list members
to give their feedback.

Joseph Pelrine mentioned as well that SUnit is available on nearly all
Smalltalk 
platforms. He is a member of the SUnit development team.

Actually you may think of unit tests as little executable scenarios. 
As the Smalltalk language is easy to read like a written text 
(as a sequence of subject-verb-object phrases) 
if the method names are well chosen
you may consider unit test code as directly beeing documentation.

To learn using the SUnit tool is very easy.
Some tests themselves are very easy to write as well. (10 minutes or so)
Others take hours. The most difficult thing is hunting for the right
method names and trying to reverse engineer the original intent of the
programmer.
However this is the problem in any kind of documentation work.

Each unit test shows a particular way of dealing 
with a particular type of object or a combination of them.

If the names of the unit tests are well chosen you have a very handy
documentation *within* a list of the SystemBrowser.

And the good thing is that the documentation can be validated
automatically
by just hitting the 'RUN ALL' button.

I suggest that we look into this issue in the documentation team. This
should
not hinder anybody else just sending in unit tests to the list. Even
just a
single test class with a single method is welcome! 
We will happily harvest them! Make sure you include the [DOCS] tag in
the subject line.


Regards
Hannes