To me, this flags a problem with the production code. Notice how the Service.count() method is simply a pass-through call to the DAO.count() method -- this construct is just useless overhead. I would rethink the purpose of having a count() method in the service class. Maybe it would be more useful to have something like this instead:
or something else that uses the size of the list to calculate a more abstract concept such as "requiresMultipleSalesRegions" or "belowMinimumRequiredLevel"
thanks for the answer.
ServiceImpl.count calls CustomerDAOImpl.count calls CustomerDAOImpl.findAll.
When my test runs into CustomerDAOImpl.findAll it should return the list with 50 entries.
I explicitly dont want to mock count(). I just want a method to be mocked which is deeper in the call hierarchy.
Sresh Rangi wrote:The service method is calling count, which is mocked to return 0 by default. In your test, you should mock the count method instead of the findAll method.
With mocks, the call hierarchy ends when it reaches the mocked interface. To use the real implementation for one method and mock another, you can use partial mocking. Mockito can do this with spies:
or you could subclass CustomerDAOImpl and override findAll to return your list.
Spies are discouraged though, because you can usually redesign the program or the tests to not require partial mocking. This results in a clearer boundary between code under test, and dependent components.