> 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?

Not that I know.

>  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 you see is that with Api you restrict a bit the changes (when they 
are well specified). Note that the assumption between the call of your 
api can also break your code. In OOPSLA 95 Strom and Yellin proposed to 
use state automata to model object. Does not scale. With white box and 
inheritance you introduce another dimension of changes.
Even if a nearly perfect world in which API would be stable, dependency 
documented.

Now imagine the following: you have a videoplayer, you refactor it, 
everything is the same at the API level now it just happens that this 
is just too slow and you end up with a slide show and not a video.
So the non-functional requirement are also really important and quite 
difficult to capture.

>  What I am interested in here is to
> understand what the causal effect(s) for our effectively blindly 
> relying on
> the environment is.

The minimal thing we should have is the possibility to identify clearly 
a component, have a bunch of
test for it.

We could have some simple tests that check that all the method used are 
present this would be a
replacement to static typing but I do not believe that you would go far 
with that.

>
> 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
>>>
>>>
>>>
>>
>>
>
>
>