"Environment tests"

Andreas Raab andreas.raab at gmx.de
Wed Nov 5 07:32:30 UTC 2003


Hi Guys,

Here's a weird and somewhat OT thought that was triggered by a discussion I
had today. One of the things I am noticing when looking at SqueakMap (and my
use of it) over the last year is that many of the packages that are
available from SM tend to break in the face of later Squeak versions. What
happens? Effectively, these packages have been written under the assumptions
of a certain environment in which they exist (namely that of Squeak X.Y) and
if these assumptions are ever (even partially) invalidated they break.

In the discussion I had today Alan (again) mentioned that one of the things
that could be done for making sure an object (or a package) can survive in
some environment is to model (at least some) of the assumptions about the
environment explicitly. We do this internally by, for example, using unit
tests for the package but typically we have no model whatsoever about our
environment. This is (at least I think so) an even larger problem for a
dynamically typed environment than it is for a statically typed environment.
In the statically typed environment you can at least be assured that the
compiler will do certain checks on your types (and messages) so unless the
semantics of some message (or type) changes you should be safe (in theory).

What I'm curious about here is: Has anyone ever seen a (hopefully even
usable ;) approach to model "environmental assumptions"? Are there any
common rules/guidelines on which "environment tests" could be based?
Anything else in this area?

Cheers,
  - Andreas




More information about the Squeak-dev mailing list