Panu,<br><br>Actually, firstElement and so on were additions to the particular test case to avoid using e.g. SequenceableCollection&gt;&gt;at: to test that SequenceableCollection&gt;&gt;at: works.&nbsp; For example,<br><br>testAt<br>
<br>&nbsp; | expectedResults |<br>&nbsp; expectedResults := #(1 4 9 16 25 36 49 64 81 100 121).<br>&nbsp; actualResults := (1 to: 11) collect: [:each | each squared].<br>&nbsp; 1 to: expectedResults size do:<br>&nbsp;&nbsp;&nbsp; [:eachIndex |<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; self assert: (expectedResults at: eachIndex) = (actualResults at: eachIndex)<br>
&nbsp;&nbsp;&nbsp; ]<br><br><br>So, instead of that,<br><br>testAt<br><br>&nbsp;&nbsp;&nbsp; actualResults := (1 to: 11) collect: [:each | each squared].<br>&nbsp;&nbsp;&nbsp; self assert: (actualResults at: 1) = self firstExpectedResult.<br>&nbsp;&nbsp;&nbsp; self assert: (actualResults at: 2) = self secondExpectedResult.<br>
&nbsp;&nbsp;&nbsp; .<br>&nbsp;&nbsp;&nbsp; .<br>&nbsp;&nbsp;&nbsp; .<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 &lt;<a href="mailto:panulogic@gmail.com">panulogic@gmail.com</a>&gt; 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>&gt; At one point I wrote an SUnit ANSI test suite for collections.<br>
&gt; Something I noticed is that it is quite easy to depend on the feature<br>&gt; you want to test to write the test in the first place. &nbsp;Particularly<br>&gt; when writing tests for things like Array or SortedCollection, the<br>
&gt; dependency on at: and at:put: becomes obvious and the whole exercise<br>&gt; appears to become a tautology.<br><br>Cycles in language-specifications can be avoided by writing the spec in<br>a &nbsp;language separate from the language being specified. No doubt any<br>
Smalltalk standard will need to rely on natural language. &nbsp;But if parts<br>of the spec can be written in Smalltalk itself, so much better, because<br>of the &nbsp;added rigor.<br><br>But consider English for a second. &nbsp;Its grammar is specified in English<br>
that&#39;s augmented with a few words that only make sense in the context of<br>the grammar (&quot;verb&quot;, &quot;noun&quot;, &quot;plural&quot; ...) - which are defined in terms<br>of the basic, everyday English. &nbsp; Similarly what you seem to be<br>
proposing is &quot;augmenting&quot; &nbsp; Collections with constructs whose sole<br>purpose is to aid in writing the &#39;&quot;standard&quot;: &nbsp;#firstElement,<br>#secondElement, &nbsp;etc.<br><br>I see no problem with this. &nbsp;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></div><div class="Wj3C7c"><br><br><br><br>_______________________________________________<br>ANSI-Smalltalk mailing list<br>
<a href="mailto:ANSI-Smalltalk@lists.openskills.org">ANSI-Smalltalk@lists.openskills.org</a><br><a 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>