Spoon progress 23 May 2006: finding dependencies via passive
ncellier at ifrance.com
Tue May 23 20:09:23 UTC 2006
Very helpful for understanding the squeak jungle, however we cannot stop here
and say, OK, we have resolved our modularity problems.
Modularity problems come when we start having different versions for the same
class>>method, and this is unavoidable in a living system.
Either two different applications i want both in my image have such a clash
directly, or they will require a third utility of different version...
Mathematically, we could write the problem as:
- we have a set of TestCase we would like to fulfil (good idea)
- we have the set of class>>method ever written in Squeak
- each class>>method has a set of versions, class>>method#n
- only a single version can exist in the image
- which partition of class_i>>method_j#n_k will light all our TestCase to
Let us imagine we have an enhanced version of Spoon to solve this problem.
When pulling methods in, inheritance must be taken into account, removed
methods are as important as added methods:
if we have a class hierarchy A > B > C, all implementing versions of method m,
and a TestCase doing (C new m), we will have to check all partitions of set
(A>>m,B>>m,C>>m). Each partition being divided into all combinations of
Too much combinatorial, i think... It could be feasible only if we group
methods in indivisible units (packages...) in order to reduce problem
And, this is a rather static view. Our modules may also trap the MNU and
process the case normally (hence we cannot eliminate the empty partition in
above case). Our modules may also well generate classes and methods
dynamically, like already possible in a true dynamic environment like
And last, this is also an ideal case, most applications simply do not have
such a TestCase collection covering 100% of their capabilities. Yes, they
should, but how do you write GUI test like when i push this button, a window
open with contents equal to...?
I did not speak of global variables (class variables mostly), which also cary
a state that can make our TestCase either succeed or fail...
Spoon is promising, but won't solve everything
Le Mardi 23 Mai 2006 20:50, Ralph Johnson a écrit :
> > Almost; the test case is started from the full image by sending a
> > message to the appropriate remote object in the minimal image, and the
> > minimal image records the transfers with a module (somewhat in the
> > manner of a changeset).
> > Module objects from different images know how to synchronize their
> > respective systems by comparing their contents, so, for example, when a
> > test case is finished, a minimal image could immediately transfer that
> > new behavior to another minimal image (which uses another new, empty
> > module).
> Is the module system new? I didn't see anything in the December
> version of Spoon like that. Maybe I just don't recognize it.
> It is a very good idea. A module is defined as all the code that is
> needed to run a test suite. To have a module, you must have tests. I
> like it!
More information about the Squeak-dev