Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expectation recorded on superclass method gets overwritten #209

Closed
Milbor-zz opened this issue Sep 17, 2015 · 2 comments
Closed

Expectation recorded on superclass method gets overwritten #209

Milbor-zz opened this issue Sep 17, 2015 · 2 comments
Assignees

Comments

@Milbor-zz
Copy link

Expectation recorded on superclass method on subclass object is overwritten if same expectation is recorded on different subclass object.

Best shown on following unit test (testng 6.9.6, jmockit 1.19) which I would expect to pass.
Is it bug? If not, could you elaborate on why it fails?

public class SpikeTest {
    public static class First extends Parent {
    }

    public static class Second extends Parent {
    }

    public static abstract class Parent {
        public String getValue() {
            return "parent";
        }
    }

    @Mocked
    private First first;
    @Mocked
    private Second second;

    @Test
    public void test() throws Exception {
        new Expectations() {{
            first.getValue();
            result = "first";

            second.getValue();
            result = "second"; //this recording overwrites previous recording on first object
        }};
        assertEquals(second.getValue(), "second");
        assertEquals(first.getValue(), "first"); //fails here, recorded "first" value is overwritten by "second"
    }
}
@rliesenfeld
Copy link
Member

It's not a bug, even if in a case like this the mocking behavior is not what one would expect; well, unless you are familiar with the exact semantics of @mocked.

Expectations recorded/verified on a @mocked instance, by default, do not care about the actual instance used during replay (the one the code under test used); they will match regardless, considering only which method was called and any arguments and argument matchers.

If the instance on which the expectation was recorded needs to match the instances at replay time, then the test should use @Injectable rather than @mocked. Alternatively, the test can use the "onInstance(mocked instance)" constraint to force instance matching.

@rliesenfeld
Copy link
Member

Perhaps @mocked semantics can be improved here; I am thinking to add a check that the class of any mocked instance is the same as the @mocked class, when comparing expectations and matching invocations to expectations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants