<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Ok, I think I now understand why you created #firstExpectedResult
etc.<br>
<br>
However from the example it seems your test is more about <br>
testing #collect: and #squared than about testing #at: .<br>
<br>
#at: and other collection protocols are important 'special' cases whose
specification I think requires special attention. <br>
<br>
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:<br>
<br>
|ob|<br>
ob := Object new.<br>
arr: = #(1 2 3).<br>
arr at: 3 put: ob.<br>
<br>
self assert: (arr at: 3) == ob.<br>
self assert: ((arr at: 2) == ob) not. <br>
<br>
self assertFails: [arr at: 4 ] .<br>
self assertFails: [arr at: 0 ] .<br>
self assertFails: [arr at: -1 ] .<br>
self assertFails: [arr at: 2.5 ] .<br>
self assertFails: [arr at: 4 put: ob ] .<br>
self assertFails: [arr at: 0 put: ob ] .<br>
self assertFails: [arr at: 2.5 put: ob ] .<br>
self assertFails: [arr at: -1 put: ob ] .<br>
<br>
<br>
The above test-case says something about both #at: and #at:put:. <br>
It doesn't unambiguously specify their complete behavior, but<br>
the standard can now say that IF an implementation fails the test-case<br>
above, it is not standards-compliant.<br>
<br>
Note also the 'suggestive' nature of the test-case above..<br>
It doesn't state every possible case in which #at: or #at:put should<br>
fail or not fail. But it does make it quite clear for a human reader <br>
what their expected behavior is. <br>
<br>
And naturally a test-case like above should be annotated with<br>
natural language instructions for "interpolating" the test-cases. <br>
But I think an executable test-case that is "reasonably representative"<br>
should be part of the spec of each standard method. <br>
<br>
It is possible that vendors already have lots and lots of test-cases <br>
for their base ST-libraries. If possible, these would be a great
starting<br>
point for the Smalltalk standardization effort.<br>
<br>
<br>
-Panu Viljamaa<br>
<br>
<br>
<br>
Andres Valloud wrote:
<blockquote
cite="mid:491b84df0802031942l36cbcf89q27be5177f133c43c@mail.gmail.com"
type="cite">Panu,<br>
<br>
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,<br>
<br>
testAt<br>
<br>
| expectedResults |<br>
expectedResults := #(1 4 9 16 25 36 49 64 81 100 121).<br>
actualResults := (1 to: 11) collect: [:each | each squared].<br>
1 to: expectedResults size do:<br>
[:eachIndex |<br>
self assert: (expectedResults at: eachIndex) = (actualResults at:
eachIndex)<br>
]<br>
<br>
<br>
So, instead of that,<br>
<br>
testAt<br>
<br>
actualResults := (1 to: 11) collect: [:each | each squared].<br>
self assert: (actualResults at: 1) = self firstExpectedResult.<br>
self assert: (actualResults at: 2) = self secondExpectedResult.<br>
.<br>
.<br>
.<br>
<br>
<br>
In the actual SUnit test suite, I think I dared up to fifthElement and
such.<br>
<br>
Andres.<br>
<br>
<div class="gmail_quote">On Feb 2, 2008 8:20 PM, Panu Logic <<a
moz-do-not-send="true" href="mailto:panulogic@gmail.com">panulogic@gmail.com</a>>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Andres
Valloud wrote:<br>
> At one point I wrote an SUnit ANSI test suite for collections.<br>
> Something I noticed is that it is quite easy to depend on the
feature<br>
> you want to test to write the test in the first place.
Particularly<br>
> when writing tests for things like Array or SortedCollection, the<br>
> dependency on at: and at:put: becomes obvious and the whole
exercise<br>
> appears to become a tautology.<br>
<br>
Cycles in language-specifications can be avoided by writing the spec in<br>
a language separate from the language being specified. No doubt any<br>
Smalltalk standard will need to rely on natural language. But if parts<br>
of the spec can be written in Smalltalk itself, so much better, because<br>
of the added rigor.<br>
<br>
But consider English for a second. Its grammar is specified in English<br>
that's augmented with a few words that only make sense in the context of<br>
the grammar ("verb", "noun", "plural" ...) - which are defined in terms<br>
of the basic, everyday English. Similarly what you seem to be<br>
proposing is "augmenting" Collections with constructs whose sole<br>
purpose is to aid in writing the '"standard": #firstElement,<br>
#secondElement, etc.<br>
<br>
I see no problem with this. It makes sense from the viewpoint that<br>
natural language standards are required to use similar means in their<br>
standards.<br>
<br>
-Panu Viljamaa<br>
<div>
<div class="Wj3C7c"><br>
<br>
<br>
<br>
_______________________________________________<br>
ANSI-Smalltalk mailing list<br>
<a moz-do-not-send="true"
href="mailto:ANSI-Smalltalk@lists.openskills.org">ANSI-Smalltalk@lists.openskills.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk"
target="_blank">http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
ANSI-Smalltalk mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ANSI-Smalltalk@lists.openskills.org">ANSI-Smalltalk@lists.openskills.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk">http://lists.openskills.org/cgi-bin/mailman/listinfo/ansi-smalltalk</a>
</pre>
</blockquote>
<br>
</body>
</html>