From lieber@ccs.neu.edu  Sat Aug  5 18:38:26 2000
From: "Karl Lieberherr" <lieber@ccs.neu.edu>
To: <lieberherr@ccs.neu.edu>
References: <006901bffb35$ec62ce40$0100a8c0@gateway>
Subject: Re: testing code leads to Demeter...
Date: Sat, 5 Aug 2000 18:38:55 -0400
Organization: Northeastern University

Hi Steve:

Thank you for your paper on Endo-Testing and Extreme Programming
with a connection to the Law of Demeter.  I have put a copy into
http://www.ccs.neu.edu/research/demeter/related-work/extreme-programming/
for our group to read. Is this ok with you?

I have studied it with interest and it gave me an
opportunity
to learn more about Extreme Programming. There seem to be interesting
connections
between Adaptive Programming a la Demeter/Java and Extreme Programming.

Testing:
The Demeter growth plan technique is very supportive of incremental testing.
When
the objects are "small" only "simple" MockSmartHandlers (that we call
visitors) are needed
to implement the desired traversal/visitor style behavior. Testing is
simplified by the grammar/class graph connection
similar to the XML schema/DOM connection that is now used in XML.
In Demeter, unit testing does not mean testing one class only but it means
testing a method
that might cut across one or several classes.

Not committing to infrastructure before you have to:
Demeter is very good at this for the case where infrastructure means the
static and dynamic structure
of objects.In Demeter/Java we program visitors against strategy graphs that
are abstractions of
"noisy" class graphs. And in APPCs (OOPSLA '98) we program in general
against a participant graph
that s also an abstraction of a "noisy" class graph.

Now regarding your email note,  I agree with you that if code violates the
LoD, then it is harder to test.
The argument is that if a method has "unnecessry" structural information in
it, we also need
to test that "unnecessary" structural information. By contraposition, if a
method is not hard to test,
it follows the Law of Demeter.

Your paper tells a slightly different story: namely that mock objects lead
to easier testability and to following
the LoD. I have not followed all your arguments but I tend to agree with
you.

I was thinking how mock objects could be used in Demeter and wrote the
following sketchy description:

The Mock Object Pattern:
Create instances of Mock Objects
Set state in the Mock Objects
Set expectations in the Mock Objects
Invoke domain code with Mock Objects as parameters
Verify consistency in the Mock Objects

DemeterJ programming style:

class Source {
  void do_something(TraversalGraph where_from_Source, Something_Visitor
something_Visitor) {
    where_from_Source.traverse(something_Visitor);
}

for example:

class Person{
  void printDetails(TraversalGraph where, PrintingVisitor printingVisitor) {
    where.traverse(printingVisitor);
}
In a call,
where = TraversalGraph(new ClassGraph(), new Strategy("from Person to
{Name,Age,Telephone}));

Mock objects invite us to develop the visitors incrementally.
Visitor mockV = new MockVisitor(); // MockVisitor is a subclass of Something_Visitor
// set state in mockV;
// set expectation in mockV;
Source s = new Source(); where_from_Source = new TraversalGraph(new
ClassGraph(), new Strategy(...));
// set s to match expectations; set where_from_Source to match expectations
s.do_something(where_from_Source, mockV);
// verify consistency in mock object;

An alternative way to test Something_Visitor Call do_something on Source /
TraversalGraph / Something_Visitor triples?
But that would be testing from the outside.

The advantage of mock visitors is that they
have access to all information in the visitor to do the testing. 
It is testing from within.

Best regards,
-- Karl


----- Original Message -----
From: Steve Freeman <steve@m3p.co.uk>
To: <lieber@ccs.neu.edu>
Sent: Monday, July 31, 2000 5:25 PM
Subject: testing code leads to Demeter...


Hello
I thought you might be interested in this paper that we had in the Extreme
Programming conference this year. We believe that we have found that
designing one'scode to be testable, as a side effect, pushes that code
towards conforming to the law of Demeter. Curious.

Yours
Steve Freeman

p.s. sorry about the format, it's what springer want.