« Return to Thread: Using ClassImposteriser isn't intuitive, is painful

Re: Using ClassImposteriser isn't intuitive, is painful

by Nat Pryce :: Rate this Message:

Reply to Author | View in Thread

Is urlFor final?

ClassImposteriser often behaves unintuitively when classes are not
implemented in a way that lets them be mocked.  If you want intuitive
mocking, don't mock classes.

--Nat

2009/4/14 T P D <lists@...>:

> Using ClassImposteriser, I'm getting not at all intuitive results.
>
> Here's my confusion: I've told Jmock to return a value for a mocked
> function. To my mind that should effectively redefine the method. Instead,
> the original method is called, and from the point where the Expectations are
> set up, not from the point that the class under test's method is called.
>
> Even more fun, this ends up with Jmock throwing an exception complaining
> that "you cannot define expectations for methods defined by the Object
> class", which I wasn't trying to do. (Full stack trace is below.)
>
> This is all a lot more painful than I expected, or recall from Jmock 1.
>
> When using
>
>    private Mockery context = new JUnit4Mockery() {{
>       setImposteriser(ClassImposteriser.INSTANCE);
>   }};
>
> my stack trace shows that methods I mean to mock are in fact being called
> when the expectations are set up:
>
>      context.checking(new Expectations() {{
>         oneOf(componentWithNotifications)
>         .wantOnSelectionChangedNotifications();
>         will(returnValue(true));
>
> // class under test should call this method
> // if wantOnSelectionChangedNotifications returns true,
> // class under test should next call urlFor
> // the next line is line 146:
>         oneOf(componentWithNotifications)
>         .urlFor(with(any(RequestListenerInterface.class)));
>         will(returnValue( "fakeUrl"));
>               }});
>
>
> I get this (partial) stack trace, called from where the expectations are set
> up:
>
>        at org.apache.wicket.RequestCycle.urlFor(RequestCycle.java:928)
>        at org.apache.wicket.Component.urlFor(Component.java:3175)
>        at
> org.diffenbach.wicket.AbstractSingleSelectChoiceStrategyTest$5.<init>(AbstractSingleSelectChoiceStrategyTest.java:146)
>
> Here's my confusion: I've told Jmock to return a value from urlFor. To my
> mind that should effectively redefine the method. Why is it instead calling
> RequestCycle.urlFor(RequestCycle.java:928), which is what the un-replaced
> method does?
>
> Even more fun, this ends up with Jmock throwing an exception complaining
> that "you cannot define expectations for methods defined by the Object
> class", which I wasn't trying to do. (Full stack trace is below.)
>
>
>
>
> java.lang.IllegalArgumentException: you cannot define expectations for
> methods defined by the Object class
>        at
> org.jmock.internal.ObjectMethodExpectationBouncer.cannotDefineExpectation(ObjectMethodExpectationBouncer.java:31)
>        at
> org.jmock.internal.ObjectMethodExpectationBouncer.fakeToString(ObjectMethodExpectationBouncer.java:27)
>        at
> org.jmock.internal.FakeObjectMethods.invoke(FakeObjectMethods.java:28)
>        at
> org.jmock.lib.legacy.ClassImposteriser$4.invoke(ClassImposteriser.java:137)
>        at
> org.diffenbach.wicket.AbstractSingleSelectChoiceStrategyTest$ComponentWithNotifications$$EnhancerByCGLIB$$3d9fd7fc.toString(<generated>)
>        at java.lang.String.valueOf(String.java:2827)
>        at java.lang.StringBuffer.append(StringBuffer.java:219)
>        at org.apache.wicket.Component.getPage(Component.java:1658)
>        at org.apache.wicket.RequestCycle.urlFor(RequestCycle.java:828)
>        at org.apache.wicket.RequestCycle.urlFor(RequestCycle.java:928)
>        at org.apache.wicket.Component.urlFor(Component.java:3175)
>        at
> org.diffenbach.wicket.AbstractSingleSelectChoiceStrategyTest$5.<init>(AbstractSingleSelectChoiceStrategyTest.java:146)
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>



--
http://www.natpryce.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


 « Return to Thread: Using ClassImposteriser isn't intuitive, is painful