3

I changed some method somewhere in our code which shouldn't have caused any weird test failures, but JMock seems to think otherwise.

I boiled the issue down to the minimal amount of cruft, which looks something like this:

import java.util.Collection;
import java.util.Collections;
import java.util.List;

import org.jmock.Expectations;
import org.jmock.Mockery;
import org.jmock.lib.legacy.ClassImposteriser;
import org.junit.Test;

public class TestMocking {

    @Test
    public void test() {
        Mockery mockery = new Mockery() {{
            setImposteriser(ClassImposteriser.INSTANCE);
        }};
        final Owner owner = mockery.mock(Owner.class);
        final RealThing thing = mockery.mock(RealThing.class, "thing");

        mockery.checking(new Expectations() {{
            oneOf(owner).getThing(); will(returnValue(thing));
            oneOf(thing).method(); will(returnValue(Collections.emptyList()));
        }});

        owner.getThing().method();

        mockery.assertIsSatisfied();
    }

    public static interface Owner {
        BaseThing getThing();
    }

    public static interface BaseThing {
        Collection<?> method();
    }

    public static interface RealThing extends BaseThing {
        List<?> method();
    }
}

(Edit: This now uses a ClassImposteriser even though there are no classes anymore, because I wanted to demonstrate that you could run the exact same code without that imposteriser and the test would pass.)

The result of running this:

unexpected invocation: thing.method()
expectations:
  expected once, already invoked 1 time: owner.getThing(); returns <thing>
  expected once, never invoked: thing.method(); returns <[]>
what happened before this:
  owner.getThing()

So there you go, "unexpected" thing.method() when the expected thing.method() was never called. I have previously seen this occur when multi-threaded classes are under test against mock objects, but this time it's all happening in a single thread. It's like JMock is somehow returning a different mock object from the first method call, even though I mocked no such object.

If I remove the overridden method which is returning a more specific type then it goes away, but I obviously can't do that. Likewise, if I remove the use of ClassImposteriser, the problem goes away, but one of the objects I'm mocking in the real test is someone else's class. I guess I could try using two Mockery instances in the one test, but aside from that I'm out of ideas.

Hakanai
  • 12,010
  • 10
  • 62
  • 132

1 Answers1

2

Hiding class (static) methods doesn't work quite the same as Overriding instance methods. To prove that JMock is not to blame here, try this:

public class test3 {
public static void main(String[] args) {
    Owner owner = new Owner();
    owner.getThing().method(); //Like how you execute your test
    RealThing thing = new RealThing();
    thing.method(); //Similar to your mock.
}

private static class Owner {
    private BaseThing thing = new RealThing();

    public BaseThing getThing() {
        return thing;
    }
}

private static class BaseThing {
    public static void method() {
        System.out.println("Basething!");
    }
}

private static class RealThing extends BaseThing {
    public static void method() {
        System.out.println("Realthing!");
    }
}
}

Note that the two calls to method() print different things! Both are instances of RealThing, but they call different methods. The static method called depends on whether it is called from the subcalss or the superclass. In the first call above, method is declared as a BaseClass, so BaseClass.method() is called, even though it is an instance of RealClass. The second call to method() is declared as a RealClass, so RealClass.method() is invoked.

So, the results from JMock are valid. The method() called was not the same as the one you set up an expectation for.

Don't feel great about my explanation of this. Please do read up on it here: http://docs.oracle.com/javase/tutorial/java/IandI/override.html


The fix (favoring BaseThing.method()), change:

final RealThing thing = mockery.mock(RealThing.class, "thing");

To:

final BaseThing thing = mockery.mock(RealThing.class, "thing");

Or if you prefer to use RealThing.method(), change:

owner.getThing().method()

To:

RealThing thing = (RealThing)owner.getThing();
thing.method();
femtoRgon
  • 32,893
  • 7
  • 60
  • 87
  • Crap, I knew that copying this down by hand would be a bad idea (my clipboard wouldn't work from IDEA to Chrome for some stupid reason.) Fixed those two spots. – Hakanai Dec 14 '12 at 02:51
  • That's certainly what I expected. Happens. Wanted a quick sanity check though. Anyway, new answer incoming presently, regarding what your actual problem is, I believe. – femtoRgon Dec 14 '12 at 03:39
  • If I remove the usage of ClassImposteriser, everything works fine (I refactored everything we were mocking that wasn't already an interface so that it was an interface, which is usually worth it anyway.) So my theory is that it is actually a bug, but your explanation of the difference probably explains the bug. I bet that the core, reflection-based imposteriser considers overridden methods to match the expectation, and the ClassImposteriser never received the same fix. – Hakanai Dec 16 '12 at 23:18
  • (actually one correction I will make - in the case of owner.getThing().method() above, it will still call the overridden method, not the BaseThing one. But if you were to take the Method object the invocation API gives you and compare it to the Method on the interface, it would only equals() the BaseThing one.) – Hakanai Dec 16 '12 at 23:20
  • @Trejkaz I'm confused. My understanding of JMock is that it is unable to mock static methods, without using the ClassImposterizer. They've been quite clear, that they don't directly support mocking static methods, and don't intend to. How could the code you show work fine with that removed? – femtoRgon Dec 17 '12 at 01:45
  • I didn't use any static methods. I refactored to remove the need to use a class, and then removed the ClassImposteriser. The interfaces didn't have to change, the interface replacing the class still returned BaseThing, and the problem went away anyway. – Hakanai Dec 18 '12 at 12:03
  • Okay, so you changed the class methods to instance methods. See the first sentance of my answer. Overriding instance methods and hiding class methods do not work the same way. When a static method call is resolved there isn't even an instance to refer to, since that happens at compile time. There is no bug. That is how Java works. It would be a bug if it didn't work that way, since JMock, in that case, would be testing a different set of calls using different logic than the unit under test. Again, this page might be helpful: http://docs.oracle.com/javase/tutorial/java/IandI/override.html – femtoRgon Dec 18 '12 at 18:54
  • I know how overriding works, but your answer above shows that you don't, so I'm not sure I can trust anything else you say. Above you're claiming that BaseClass.method() is called, which simply isn't true no matter what. – Hakanai Dec 18 '12 at 23:47
  • I have no idea where you are getting the idea about class methods from, because my original question never even used them. I just discovered that your example was including some, so I have removed the static keyword from your example so that it is consistent with the question. – Hakanai Dec 18 '12 at 23:56
  • Did you try running the example I provided in my answer As Written? It clearly demonstrates BaseClass.method being called. – femtoRgon Dec 18 '12 at 23:57
  • Is that still true now that I have corrected it? I get "Realthing!" for both lines once I removed the statics which were never in my question anyway. – Hakanai Dec 18 '12 at 23:57
  • Now I've changed the question to remove the only class as well. This makes the ClassImposteriser unnecessary but as you can see, it still fails - only now, remove the ClassImposteriser and it passes. – Hakanai Dec 19 '12 at 00:07
  • Okay, I see where I misunderstood you there. I saw static method declarations instead of static class declarations. In that case, yes, this behavior doesn't strike me as correct. – femtoRgon Dec 19 '12 at 03:34