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?
|
