Java – Is it really a bad practice to mock a POJO (value object) if you don’t care about what it contains

javamockingtddvalue-object

In the advice of Mockito about how to write good tests, it is written that we should not mock value objects (https://github.com/mockito/mockito/wiki/How-to-write-good-tests#dont-mock-value-objects). They even say

Because instantiating the object is too painful !? => not a valid
reason.

But I don't understand. What if we really don't care about what that object contain?
Let's just say that I have a value object class "Foo" that doesn't have simple constructors (it has an all-args constructor and contains objects that also need all-args constructors).
Let's also say I have the following service:

public class MyService {
    private SomeService someService;
    private OtherService otherService;

    public void myAwesomeMethod() {
        Foo foo = someService.getFoo();
        someOtherService.doStuff(foo);
    }
}

And I need to test that method. Clearly here I don't care about what foo contains because I just pass it to another method. If I want to test it should I really create a foo object with nested constructors/builders? For me it would be really easy to mock foo even if it is a POJO :

public class MyServiceTest {
    @InjectMocks
    MyService myService;

    @Mock
    private SomeService someService;

    @Mock
    private OtherService otherService;

    @Test
    public void testMyAwesomeMethod() {
        Foo mockedFoo = Mockito.mock(Foo.class);

        Mockito.when(someService.getFoo()).thenReturn(mockedFoo);

        Mockito.verify(otherService).doStuff(mockedFoo);
    }

}

But then it wouldn't respect the guidelines given by Mockito. Is there another alternative?

Best Answer

Stubs (that you've called mocks in your question) exist for a reason: they make it possible to replace business code from the classes you depend on in the method you're testing by some very basic statements which provide enough data for the tested method. Mocks, just like stubs, replace business logic by custom logic required for the tests.

If a POJO doesn't have business code (i.e. if it's also a data object), stubs and mocks would be useless. Using such data objects in tests should be quite easy. If the method needs a data object in input, just create one in the test.

Some data objects may be very large, containing dozens of properties. In some languages, you can partially initialize a data object by setting only the properties you need during the test; in other languages, you need to fully initialize it. If this is your case, creating a simple static method which creates the data object with the default values and reusing this method all over the tests could be a solution.
If a POJO contains business code, you should isolate your unit tests from it, like you would do for any other class. Here, stubs and mocks are fine, and it doesn't make a difference if the mocked object is a POJO or something else.

Related Solutions

Python Unit Testing – How to Populate a Private Container?

Until recently, I would have just pointed you at plenty of other existing questions that say that you generally shouldn't need access to any private stuff, in order to write unit tests - as the whole point of tests is to test the public (and protected) interface.

For example, in the question how to unit-test private methods in jquery plugins?, there is this answer:

The same applies here as with any other language and testing privates: To test private methods, you should exercise them via the public interface. In other words, by calling your public methods, the private methods get tested in the process because the public methods rely on the privates.

Generally private methods are not tested separately from the public interface - the entire point is that they are implementation details, and tests should generally not know too much about the specifics of the implementation

In your specific case, you say:

Since the data is private, I can only add things via the public interface of the object. This run codes that need not be run during a unit test and in some case is just a copy and paste from another test.

I would be cautious about having any tests that avoided code that normally needs to be run - for fear that your tests would spuriously pass, due to some difference between the test behaviour and the real world.

Having said all that, I recently learned about a really excellent article on writing testsuite called The Way of Testivus. It's a PDF that's only 12 pages long, and a really easy and enjoyable read.

What's relevant here is the section entitled "Sometimes, the test justifies the means" - in the context of violating encapsulation to enable testing. I highly recommend it.

(Another favourite of mine is "An ugly test is better than no test.")

So, in your context, if you still decide you really want a different way to set up data purely for tests, it might be reasonable to add a public setter method, specifically documented as only existing to aid writing of tests.

Appropriate Use of Mockito’s Reset Method

I believe this is one of the cases where using reset() is ok. The test you are writing is testing that "some things" triggers a single call to someMethod(). Writing the verify() statement with any different number of invocations can lead to confusion.

atLeastOnce() allows for false positives, which is a bad thing as you want your tests to always be correct.
times(2) prevents the false positive, but makes it seem like you are expecting two invocations rather than saying "i know the constructor adds one". Further more, if something changes in the constructor to add an extra call, the test now has a chance for a false positive. And removing the call would cause the test to fail because the test is now wrong instead of what is being tested is wrong.

By using reset() in the helper method, you avoid both of these issues. However, you need to be careful that it will also reset any stubbing you have done, so be warned. The major reason reset() is discouraged is to prevent

bar = mock(Bar.class);
//do stuff
verify(bar).someMethod();
reset(bar);
//do other stuff
verify(bar).someMethod2();

This is not what the OP is trying to do. The OP, I'm assuming, has a test that verifies the invocation in the constructor. For this test, the reset allows for isolating this single action and it's effect. This one of the few cases with reset() can be helpful as. The other options that don't use it all have cons. The fact that the OP made this post shows that he is thinking about the situation and not just blindly utilizing the reset method.

Best Answer

Related Solutions

Python Unit Testing – How to Populate a Private Container?

Appropriate Use of Mockito’s Reset Method

Related Topic