Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F870653.1000707@apache.org>
Date: Fri, 10 Oct 2003 21:19:47 +0200
From: Ugo Cei <ugo@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030619
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Testing serviceable components
References: <3F86C1AF.3020107@cbim.it> <3F86E635.7080000@mm.st>
In-Reply-To: <3F86E635.7080000@mm.st>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Steve K wrote:
> I don't know if this will help you, but I've been experimenting with 
> using the CocoonBean in my test cases.  You could create a subclass of 
> the CocoonBean class that will expose the getComponentManager() method 
> to your test case.  You could then use that method to create and test 
> the component.

Thank you, but I already have a ComponentManager provided by 
ExcaliburTestCase, however what I need is a ServiceManager.

Anyway, after some thinking I came to the conclusion that the class I 
want to test (o.a.c.woody.datatype.DynamicSelectionList) does not need 
either a ComponentManager or a ServiceManager. Its generateSaxFragment 
method should be passed a Source and should not get one from a 
SourceResolver that in turn it gets from a ServiceManager:

public void generateSaxFragment(ContentHandler contentHandler, Locale 
locale, Source source) throws ProcessingException, SAXException, 
IOException {
     SelectionListHandler handler = new SelectionListHandler(locale);
     handler.setContentHandler(contentHandler);
     SourceUtil.toSAX(source, handler);
}

Why? Well, because, according to the Law of Demeter ([1]), any method of 
an object should call only methods belonging to:

- itself
- any parameters that were passed in to the method
- any objects it created
- any directly held component objects.

The current implementation of generateSaxFragment violates this law by 
calling a method on an object (Source) returned by a method called on an 
object (SourceResolver) returned by a method called on a directly held 
object (ServiceManager): two levels of indirection more than necessary. 
This creates a tight and unnecessary coupling between 
DynamicSelectionList, SourceResolver and ServiceManager.

By refactoring the way I plan to, we get the added benefit that we can 
get a Source from wherever we like, be it a ComponentManager or a 
ServiceManager or maybe some mock implementation, easing testability.

What do you people think?

	Ugo

[1]: http://www.ccs.neu.edu/home/lieber/LoD.html