Question

I’m unit testing with easymock and having a result not set in the answer object. The mock object is passed to the testing subject and after processing the same reference of the mock object is returned, but it doesn’t hold the result set to it.

The code should make the picture clearer

@Test
public void test() {
DomainInterface mock = EasyMock.create("mock", DomainInterface.class);
Subject subject = new Subject();
subject.setDomainInterface(mock);

final DomainInterface domain = subject.process();

assertEquals("Not the same instance", mock, domain);

final String expected = "VALID";
final String answer = domain.getAnswer();

assertEquals("Not the expected answer", expected, answer);
}

What Subject.process is doing is a couple of validations and then setting “VALID” to the answer, but the execution fails with the assertion error message

java.lang.AssertionError: Not the expected answer expected:<VALID> but was:<null>

The subject object has a private member of type DomainInterface where the mock’s reference is set, why would the answer not hold till the assertion?

Thanks in advance

Answer 1

I’ve just noticed that you’re asserting that the same mock is being returned. You’re also never calling replay() to put the mock into replay mode – if you had, it would throw an exception as soon as Subject tried to call any methods on it.

My guess is that you’re expecting the mock to remember a call to setAnswer and reply with the same result when getAnswer is called – but mocking doesn’t work like that. You should probably expect a call to setAnswer("VALID"). Something like this:

public void test() {
    DomainInterface mock = EasyMock.create("mock", DomainInterface.class);

    // Expect that the subject will call setAnswer with an argument of "VALID"
    mock.setAnswer("VALID");

    EasyMock.replay();

    Subject subject = new Subject();
    subject.setDomainInterface(mock);

    DomainInterface domain = subject.process();    
    assertEquals("Not the same instance", mock, domain);

    // No need to assert the result of calling getAnswer - we've already asserted
    // that setAnswer will be called.
}

Personally I’m becoming a fan of hand-written fakes for many tests – mocks are great for interaction testing (aka protocol testing) but in this situation it looks like a simple fake would do just as well… or possibly a mixture, which fakes out the simple bit (the property) but allows mocks for the bits which require interaction testing.