Using ClassImposteriser isn't intuitive, is painful

View: New views
3 Messages — Rating Filter:   Alert me  

Using ClassImposteriser isn't intuitive, is painful

by T P D-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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



RE [jmock-user] Using ClassImposteriser isn't intuitive, is painful

by ar92 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Looks like the method "urlFor()" is declared final, so you can't mock it.

You may need to wrap the RequestCycle in another object that you can mock.
-Alan






T P D <lists@...>

14/04/2009 05:48
Veuillez répondre à
user@...

A
user@...
cc
Objet
[jmock-user] Using ClassImposteriser isn't intuitive, is painful





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




Re: Using ClassImposteriser isn't intuitive, is painful

by Nat Pryce :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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