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