[DOCS] SUnit tests (was Re: Documentation [was: Morphic tutorial])

Hannes Hirzel hannes.hirzel.squeaklist at bluewin.ch
Thu Feb 13 11:55:46 UTC 2003


Unit Tests

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
He was 
> > pointing to
> > "code based" documentation which I interpret as a documentation of the
> > implementation rather than the architecture.
> Yes

Thank you for pointing out once again the importance of unit tests ;-)

> For me test should tell some small scenario in terms of the object 
> interfaces
> as you want to have a low speed change for tests.
> Of course when there is a vicious point having a simple test is always 
> cool to catch it after.

> Just a fun and true story. Alex wrote during the last two months an 
> implementation
> of a module system for smalltalk. He wrote all kind of tests that 
> capture the semantics we wanted. Then we discussed with steven and 
> realized that his implementation was cooler. Alex reimplemented the 
> core model in  ***one afternoon*** and told me: "this is fascinating because 
> all the tests run so the model should work. amazing." and it was 
> working.

(Emphasis HH)
> That's the power of tests. Specifying behavior. After this is clear 
> that you have to take care
> about the granularity you want to have.

Questions / Notes

May I ask you to send in as a convenience the URL to your 5 pages
intro paper to Unit tests.

A unit test browser is now included in the 3.4 release. 
Implementin a test is as easy as adding your own TestCase subclass in 
the category you are working. 
It shows up automatically in the UnitTest-Browser.

As an aid for the documentation people: 
Stephane, where do you see the most urgent need for additional tests?

(a list with priorities if possible)

> > Architectural issues (like how
> > things "should" be - notice the use of phrases like "typically" or "by
> > default" in the little blurb I wrote) cannot be covered by unit tests 
> > very
> > well.
> Indeed this could be a pain.

> > Similarly to "usage information" (e.g., how-to) since tests typically
> > have the wrong "usage density" (e.g., there should be tests for all the
> > #addMorph: variants none of which tells you that "the way to go" is to 
> > use
> > #addMorph: - tests actually can be confusing for this kind of 
> > information).
> > I'm sure Stephane is well aware of this.


More information about the Squeak-dev mailing list