[ANSI-Smalltalk] squeakers

[Panu Logic]

Ok, I think I  now understand why you  created  #firstExpectedResult  etc.

However from the example it seems your test is more about
testing #collect: and #squared  than about testing #at:  .

#at: and other collection protocols are important 'special' cases whose 
specification I think requires special attention.

I would approach the specification of  #at: from the viewpoint that we 
are not trying to specify individual methods in isolation, but a 
standard set of methods that interact with each other.  Thus the 
specification of #at: could be partially done in terms of #at:put:,  and 
vice versa:

 |ob|
 ob := Object new.
 arr: =   #(1 2 3).
 arr  at: 3 put: ob.

 self assert: (arr at: 3) == ob.
 self assert: ((arr at: 2) == ob) not.

 self assertFails:  [arr at: 4                   ] .
 self assertFails:  [arr at: 0                   ] .
 self assertFails:  [arr at: -1                  ] .
 self assertFails:  [arr at: 2.5                ] .
 self assertFails:  [arr at: 4   put:  ob   ] .
 self assertFails:  [arr at: 0    put:  ob  ] .
 self assertFails:  [arr at: 2.5  put:  ob ] .
 self assertFails:  [arr at: -1   put:  ob  ] .
 

The above test-case says something about both #at: and #at:put:.
It doesn't unambiguously specify their  complete behavior, but
the standard can now say that IF an implementation fails the test-case
above, it is not standards-compliant.

Note also the 'suggestive' nature of the test-case above..
It doesn't state every possible case in which #at: or #at:put should
fail or not fail. But it does make it quite clear for a human reader
what their expected behavior is. 

And naturally  a test-case like above should be annotated with
natural language instructions for "interpolating" the test-cases.
But I think an executable test-case that is "reasonably representative"
should be part of the spec of each standard method. 

It is possible that vendors already have lots and lots of test-cases
for their base ST-libraries. If possible, these would be a great starting
point for the Smalltalk standardization effort.


-Panu Viljamaa



Andres Valloud wrote:
> Panu,
>
> Actually, firstElement and so on were additions to the particular test 
> case to avoid using e.g. SequenceableCollection>>at: to test that 
> SequenceableCollection>>at: works.  For example,
>
> testAt
>
>   | expectedResults |
>   expectedResults := #(1 4 9 16 25 36 49 64 81 100 121).
>   actualResults := (1 to: 11) collect: [:each | each squared].
>   1 to: expectedResults size do:
>     [:eachIndex |
>       self assert: (expectedResults at: eachIndex) = (actualResults 
> at: eachIndex)
>     ]
>
>
> So, instead of that,
>
> testAt
>
>     actualResults := (1 to: 11) collect: [:each | each squared].
>     self assert: (actualResults at: 1) = self firstExpectedResult.
>     self assert: (actualResults at: 2) = self secondExpectedResult.
>     .
>     .
>     .
>
>
> In the actual SUnit test suite, I think I dared up to fifthElement and 
> such.
>
> Andres.
>
> On Feb 2, 2008 8:20 PM, Panu Logic <panulogic at gmail.com 
> <mailto:panulogic at gmail.com>> wrote:
>
>     Andres Valloud wrote:
>     > At one point I wrote an SUnit ANSI test suite for collections.
>     > Something I noticed is that it is quite easy to depend on the
>     feature
>     > you want to test to write the test in the first place.  Particularly
>     > when writing tests for things like Array or SortedCollection, the
>     > dependency on at: and at:put: becomes obvious and the whole exercise
>     > appears to become a tautology.
>
>     Cycles in language-specifications can be avoided by writing the
>     spec in
>     a  language separate from the language being specified. No doubt any
>     Smalltalk standard will need to rely on natural language.  But if
>     parts
>     of the spec can be written in Smalltalk itself, so much better,
>     because
>     of the  added rigor.
>
>     But consider English for a second.  Its grammar is specified in
>     English
>     that's augmented with a few words that only make sense in the
>     context of
>     the grammar ("verb", "noun", "plural" ...) - which are defined in
>     terms
>     of the basic, everyday English.   Similarly what you seem to be
>     proposing is "augmenting"   Collections with constructs whose sole
>     purpose is to aid in writing the '"standard":  #firstElement,
>     #secondElement,  etc.
>
>     I see no problem with this.  It makes sense from the viewpoint that
>     natural language standards are required to use similar means in their
>     standards.
>
>     -Panu Viljamaa
>
>
>
>
>     _______________________________________________
>     ANSI-Smalltalk mailing list
>     ANSI-Smalltalk at lists.openskills.org
>     <mailto:ANSI-Smalltalk at lists.openskills.org>
>     http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ANSI-Smalltalk mailing list
> ANSI-Smalltalk at lists.openskills.org
> http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openskills.org/pipermail/ansi-smalltalk/attachments/20080204/26d13077/attachment.html