Re: [Mockobjects-java-users] Chicken and egg problem

[Steve F. <st...@m3...>]

Interesting problem.

Personally, I'd suggest getting the content handler after the fact and just
checking its identity in an assert (not an assertEquals). You might even do
this with a real XMLReader if it's easy to construct.

  MockXMLReader reader = new MockXMLReader();
  BaseContentHandler handler = new BaseContentHandler( reader ) ;
  assert("Should be same content handler", handler ==
reader.getContentHandler());

The reason we normally set expectations first is to make the tests
consistent and so that the test can explode in the right place. Given that
in this case the getter already exists, we lose nothing by using it.

An alternative, depending on what you want to test, would be just to count
the number of times setContentHandler() gets called, if you're confident
enough that the right value will be set -- but I suspect not.

Steve

> I have a situation where when I construct an object I pass an object to
the
> constructor that the constructor will call a method on with itself as a
> parameter. This is part of a SAX parser and the object being constructed
is
> a ContentHandler. The object being passed to the constructor is the
> XMLReader that the object being constructed is to register itself with.
>
> The constructor looks like this:
>
> public BaseContentHandler( XMLReader reader )
> {
> this.parentHandler = reader.getContentHandler();
> this.reader = reader;
> reader.setContentHandler( this );
> }
>
> You can see this pattern in the XML parsing code in the Ant project (which
> is where I got the idea). Whether this is a good pattern is debatable, but
> either way it should be testable.
>
> I created a MockXMLReader object to verify that the constructed object is
> setting itself as the content handler. The setContentHandler method calls
> setActual on an ExpectationValue. The problem is that I cannot set the
> expected value until the constructor returns because I don't have an
object
> reference until the constructor returns. But the setExpected call does a
> clearActual which clears the actual value just set within the constructor.
>
> So I have a problem of which comes first the chicken or the egg or in this
> case the expected or the actual. The question is how to solve it and
should
> Mock Objects be changed to make this easier?
>
[...]
> The question boils down to is there any reason why the expected must be
set
> before the actual? Any thoughts?