At one point I wrote an SUnit ANSI test suite for collections.&nbsp; 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.&nbsp; 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.<br>
<br>Something I found useful to get out of this situation is to implement messages such as #firstElement, #secondElement, ..., #fifthElement in the test case, and then to refer to particular objects that should be found at given at: indices via those messages.&nbsp; It makes for a somewhat cumbersome implementation.&nbsp; However, it is easier to show that tests written in that way are more valuable than tests for e.g. at: that rely on at:.<br>
<br>The other issue is that the idea of what is an Array can be expressed as a test, and yet implementations that comply with the test can be quite different than what what we would expect them to look like.&nbsp; For example, one could make an array as a subclass of Dictionary and while it would pass all the tests, it may not qualify as straightforward as other possible implementations.&nbsp; To a point I think particular situations like these are unavoidable, and that we should not spend much energy dealing with them.&nbsp; I think we should rather concentrate on making sure the test is as far from a tautology as (with reason) possible.<br>
<br>Andres.<br><br><div class="gmail_quote">On Jan 25, 2008 12:35 PM, Bruce Badger &lt;<a href="mailto:bwbadger@gmail.com">bwbadger@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;">
<div class="Ih2E3d">On 25/01/2008, Michael Klein &lt;<a href="mailto:mklein@alumni.caltech.edu">mklein@alumni.caltech.edu</a>&gt; wrote:<br>&gt; Well that just begs the question:<br>&gt;<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; How does one determine whether any given test<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; actually tests for compliance to a specification?<br><br></div>A very good question. &nbsp;I think that the answer is that neither the<br>specifications nor the tests will ever be perfect, but each will help<br>the other to trend towards being prefect.<br>
<br>Let me add that the above assumes that we have diligent (but<br>different!) people working on the specification and the tests.<br><div><div></div><div class="Wj3C7c"><br>--<br>Make the most of your skills - with OpenSkills<br>
<a href="http://www.openskills.org/" target="_blank">http://www.openskills.org/</a><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>