"Environment tests"

Roel Wuyts Roel.Wuyts at ulb.ac.be
Wed Nov 5 09:50:47 UTC 2003


[Sorry, quite a long mail but I give some concrete example to make the 
little 'lecture' more clear - I hope :-) ]

Several techniques try to achieve this. For example, there is some work 
done by Carine Lucas and all that you can have a look at. It is called 
'Reuse Contracts'. Quite old now, but still valid and I could parts of 
it see working in practice. The idea is to annotate every method with a 
bit more information about what it does, and use this information to 
see whether things can still work together. To give a simple example...

Suppose I have a List class, which has two methods: #add: (adds the 
argument object to the list) and addAll: (adds every element in the 
passed list to the receiver).
Suppose I now want to make a subclass that counts its elements. I will 
override the #add: method to add the element and increment an internal 
counter. But do I need to override #addAll: as well? Without looking at 
the code, there is no way that I can tell. If the #addAll: on List 
invokes #add:, then I will count the right thing. If #addAll: directly 
adds the elements without using #add:, I will miss them. I have to go 
and look at the code. Typing systems will not help you against this 
trivial example, because it is not concerned with what goes on inside a 
method, only what kind of things go in and out. The basic idea of reuse 
contracts is to annotate each method with its self-sends; this solves 
the example given here nicely, and allows to build a matrix of cnflicts 
about what kind of operations will go together without problem and 
which won't. So you could analyze whether something on SqueakMap will 
be loadable or not. For more references check out the publications page 
on http://prog.vub.ac.be (search for 'reuse contracts' - there is three 
Ph.D. thesisses and several papers) or ask me.

Note that with reuse contracts not all possible conflicts will be 
detected.... to do this you would need to document everything which 
goes on in the code, which is the code. For this there are formal 
techniques that can be used to really prove your code (the new computer 
science department in Brussels where I work now have a lot of people 
doing this). In short: because of the sheer (mathematical) complexity 
there is still much more that cannot be proven than what can be, 
Reflection for example causes huge problems for all of the formalisms 
they are usng (theorem provers etc.).

So there is tons of stuff out there (these were just two things), but 
none of them is really very practical to use. Like Stephane said, 
version numbers is the currently accepted technique, simply because it 
is easy and because it is the responsibility of whoever makes the 
component to provide a number (and there is no automatic tool that 
tries to be smart about anything).

Apart from that there are several things one can do in practice. Like 
adding pre-postconditions, running unit tests every time they are 
available to at least have an idea about the problem, ...  So yesterday 
when Adam told me that the SystemChangeNotification was broken for 
Squeal 3.7 I loaded them in 3.7, ran my tests, and fixed the problem. 
This is a very pragmatic, working solution to assess whether there is a 
problem when you load something, and where to start fixing it. Version 
numbers will just give you one set of combinations which is supposed to 
work, but not what to do when it does not. Never had problems 
installing certain Linux packages, where some pieces need this version 
and other pieces need that version and you can;t work it out :-( ?

On Wednesday, Nov 5, 2003, at 09:06 Europe/Zurich, ducasse wrote:

> 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




More information about the Squeak-dev mailing list