cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <>
Subject Mock objects
Date Fri, 23 Jul 2004 17:05:26 GMT
In the Cocoon tests one can find a handful of "Mock Objects", for 
instance in the o.a.c.environment.mocks package. These mocks are used 
to stub out objects that are hard and/or expensive to create or 
manipulate, like a Request or Environment. You can carry out a certain 
number of tests with this kind of mocks, but there are limits. One 
limit is that you cannot easily set up and test expectations regarding 
the interaction between the method under test and its "fixture" which 
can be made up of such mocks. Imagine, for example, that you want to 
test the connectPipeline method of AbstractProcessingPipeline:

      * Connect the next component
     protected void connect(Environment environment,
                            XMLProducer producer,
                            XMLConsumer consumer)
     throws ProcessingException {
         XMLProducer next = producer;
         // Connect next component.

      * Connect the XML pipeline.
     protected void connectPipeline(Environment environment)
     throws ProcessingException {
         XMLProducer prev = this.generator;

         Iterator itt = this.transformers.iterator();
         while (itt.hasNext()) {
             Transformer next = (Transformer);
             connect(environment, prev, next);
             prev = next;

         // insert the serializer
         connect(environment, prev, this.lastConsumer);

A possible test is verifying that the setConsumer method on the 
generator is called with the correct argument, like a transformer. How 
can you do that if the XMLProducer class does not provide a getConsumer 
method? We could add it, but it would force all implementors to provide 
an implementation and it would not be possible if the interface in 
question were from an external library.

What is needed is an implementation of XMLConsumer that provides a way 
to set an expectation that the setConsumer method will be called and 
verify if this is indeed the case. Simple stubs do not provide this 
capability. This is why some people started drawing a line between 
simple "stubs" and "real mocks". You can read more about this here [1].

Now, implementing mock objects for the interfaces we want to mock is 
not that hard but is tedious and is better left to tools. There are a 
couple of Java libraries out there that are meant to be used with JUnit 
and that we could add to our arsenal:

- jMock
- EasyMock

What I am asking here is whether someone has experience with the above 
mentioned frameworks and feels like suggesting one over the other, or 
maybe a third alternative.

	Thanks in Advance,



Ugo Cei -
View raw message