Re: [MO-java-users] MockDirContext.setExpectedSearch(...) not useful due to SearchCon trols.equals()

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

speaking entirely off the cuff...

I see two options: add equals (and hashCode) methods to the test version 
of the SearchControls object so that it matches, or control the creation 
of the SearchControl object, perhaps through a passed-in factory, so 
that you can pass the same instance around.

The dynamic jmock library we're working on includes support for more 
flexible constraints than just equals.

S.


Demyanovich, Craig - Apogent wrote:
> I'm having problems using MockDirContext.setExpectedSearch(...).  Both my
> test and my code create a SearchControls instance and configure it with the
> same properties, i.e., two separate instances that are logically equal.
> However, the test fails with this message:
> 
> junit.framework.AssertionFailedError: mySearchControls did not receive the
> expected Value.
> 
> I learned that MockDirContext.verify(), inherited ultimately from
> MockObject, relies on the equals() implementation of the various expected
> and actual fields of MockDirContext.  I then decided to test the equals()
> implementation of SearchControls, and I discovered that it is inherited from
> java.lang.Object.  Therefore, it provides only reference equality and not
> logical equality.
> 
> Consequently, MockDirContext.setExpectedSearch(...) doesn't work as desired.
> If anyone does not agree with my analysis, please correct me.  Otherwise,
> has anyone taken any steps to address this with the Java team in general or
> the JNDI team in particular?