I think you already answered it: it is a reengineering problem. Not a 
lot of people are interested in documenting a (huge) existing system 
even provided to understand it enough. And if they don't even 
understand it... " aomebody else who understands this better than me 
will do this", right?

Then I see something else: unit tests are unit tests. They are quite 
good at expressing functional aspects on a certain scale. But it is too 
low-level to describe bigger invariants (on the higher-level design 
level/architectural level, for example). That also makes it harder.

On Wednesday, Nov 5, 2003, at 09:15 Europe/Zurich, Andreas Raab wrote:

> Hi Stef,
>
> Thanks for the info. One thing I am wondering about is the following. 
> When
> we write tests, we typically model our "internal assumptions" quite
> precisely which helps us to track may of the problems that occur when 
> those
> assumptions (even slightly) change. Is there anything in research that
> explains why we don't do this on the environment? Is it just 
> considered too
> big a task? Or is it that we merely assume that we have an unchanging 
> target
> (which requires people/vendors to fix the API once and forever)? Or is 
> it
> that - because in many cases we simply don't know enough about the
> environment (black box reuse) - we don't even know what assumptions we 
> (and
> the environemnt itself) is making? What I am interested in here is to
> understand what the causal effect(s) for our effectively blindly 
> relying on
> the environment is.
>
> Just curious,
>   - Andreas
>
>> -----Original Message-----
>> From: squeak-dev-bounces at lists.squeakfoundation.org
>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
>> Behalf Of ducasse
>> Sent: Wednesday, November 05, 2003 9:06 AM
>> To: The general-purpose Squeak developers list
>> Subject: Re: "Environment tests"
>>
>>
>> Hi andreas
>>
>> Even with Java or languages with a static type system,
>> nothing prevents
>> you that your system will break. There are a lot of research
>> papers on
>> that and none
>> provide a good solution. Between one version and another one the same
>> interface
>> can hold but the behavior slightly changes and break everything
>> (fragile base problem for example).
>>
>> The minimal first step would be to be able to rely on well-known and
>> identifiable versions of other components (package).
>>
>> Stef
>>
>> On Mercredi, nov 5, 2003, at 08:32 Europe/Zurich, Andreas Raab wrote:
>>
>>> 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
>>>
>>>
>>>
>>
>>
>
>
>
Roel Wuyts                                                              
   DeComp
roel.wuyts at ulb.ac.be                               Université Libre de 
Bruxelles
http://homepages.ulb.ac.be/~rowuyts/                                    
Belgique
Board Member of the European Smalltalk User Group: www.esug.org