List of Classes and Methods of org.mockito.runners package of Mockito Framework

I finally figured it out...

Sometimes, asking a question can give you a better approach to your problems :p

The problem is I was linking the validators to the list before they were mocked. The validators was then null and no reference could be updated when the MockitAnnotations.initMocks(this) was called.

Moreover, to avoid iterator problems on List, I had to use @Spy instead of @Mock.

Here is the final solution:

@Mock
private EsmRegexValidator regexValidator;

@Mock
private EsmFormNotNullValidator notNullValidator;

@Mock
private EsmFormDataTypeValidator dataValidator;

@InjectMocks
private EsmFormValidatorManager validatorManager;

@Spy
private List<IEsmFormValidator> validators = new ArrayList<IEsmFormValidator>();

@Mock
private ColumnDTO columnDTO;

@Before
public void init() {

    MockitoAnnotations.initMocks(this);

    validators.add(notNullValidator);
    validators.add(regexValidator);
    validators.add(dataValidator);

    Mockito.when(columnDTO.getTitle()).thenReturn("Mock title");
    Mockito.when(columnDTO.getName()).thenReturn("Mock name");
}

You can accomplish what you want with Mockito's argument matchers:

myObject.doSomeStuff();

verify(myMockedOtherObject, never()).someMethodOrOther(
    Mockito.anyString(),
    Mockito.anyString()
);

You can make that a little less verbose with a static import like you have for verify and never.

Well, the common approach to data storage in Java is, as you noted, not at all very object-oriented. This is in and of itself neither bad nor good: "object-orientedness" is neither an advantage nor disadvantage, it's just one of many paradigms, that sometimes helps with good architecture design (and sometimes not).

The reason DAOs in Java aren't usually object-oriented is exactly what you want to achieve – relaxing your dependency on the database. In a better-designed language, that allowed for multiple inheritances, this, of course, can be done very elegantly in an object-oriented way, but with Java, it just seems to be more troublesome than it is worth.

In a broader sense, the non-OO approach helps decouple your application-level data from the way it is stored. This is more than (non-)dependency on the specifics of a particular database, but also the storage schemas, which is especially important when using relational databases (don't get me started on ORM): you can have a well-designed relational schema seamlessly translated into the application OO model by your DAO.

So, what most DAOs are in Java nowadays are essentially what you mentioned in the beginning – classes, full of static methods. One difference is that, instead of making all the methods static, it is better to have a single static "factory method" (probably, in a different class), that returns a (singleton) instance of your DAO, which implements a particular interface, used by application code to access the database:

public interface GreatDAO {
    User getUser(int id);
    void saveUser(User u);
}
public class TheGreatestDAO implements GreatDAO {
   protected TheGreatestDAO() {}
   ... 
}
public class GreatDAOFactory {
     private static GreatDAO dao = null;
     protected static synchronized GreatDao setDAO(final GreatDAO d) {
         final GreatDAO old = dao;
         dao = d;
         return old;
     }
     public static synchronized GreatDAO getDAO() {
         return dao == null ? dao = new TheGreatestDAO() : dao;
     }
}

public class App {
     void setUserName(final int id, final String name) {
          final GreatDAO dao =  GreatDAOFactory.getDao();
          final User u = dao.getUser(id);
          u.setName(name);
          dao.saveUser(u);
     }
}

Why do it this way as opposed to static methods? Well, what if you do decide to switch to a different database? Naturally, you'd create a new DAO class, implementing the logic for your new storage. If you were using static methods, you would now have to go through all your code, accessing the DAO, and change it to use your new class, right? This could be a huge pain. And what if then you change your mind and want to switch back to the old DB?

With this approach, all you need to do is to change the GreatDAOFactory.getDAO() and make it create an instance of a different class, and all your application code will be using the new database without any changes.

In real life, this is often done without any changes to the code at all: the factory method gets the implementation class name via a property setting, and instantiates it using reflection, so, all you need to do to switch implementations is to edit a property file. There are actually frameworks – like spring or guice – that manage this "dependency injection" mechanism for you, but I won't go into details, first, because it is really beyond the scope of your question, and also, because I am not necessarily convinced that the benefit you get from using those frameworks is worth the trouble integrating with them for most applications.

Another (probably, more likely to be taken advantage of) benefit of this "factory approach" as opposed to "static" is testability. Imagine that you are writing a unit test that should test the logic of your App class independently of any underlying DAO. You don't want it to use any real underlying storage for several reasons (speed, having to set it up, and clean up afterwards, possible collisions with other tests, the possibility of polluting test results with problems in DAO, unrelated to App, which is actually being tested, etc.).

To do this, you want a test framework, like Mockito, that allows you to "mock out" the functionality of any object or method, replacing it with a "dummy" object, with predefined behavior (I'll skip the details, because, this again is beyond the scope). So, you can create this dummy object replacing your DAO, and make the GreatDAOFactory return your dummy instead of the real thing by calling GreatDAOFactory.setDAO(dao) before the test (and restoring it after). If you were using static methods instead of the instance class, this would not be possible.

One more benefit, which is kinda similar to switching databases I described above is "pimping up" your DAO with additional functionality. Suppose that your application becomes slower as the amount of data in the database grows, and you decide that you need a cache layer. Implement a wrapper class, that uses the real DAO instance (provided to it as a constructor parameter) to access the database, and caches the objects it reads in memory so that they can be returned faster. You can then make your GreatDAOFactory.getDAO instantiate this wrapper, for the application to take advantage of it.

(This is called "delegation pattern" … and seems like a pain in the butt, especially when you have lots of methods defined in your DAO: you will have to implement all of them in the wrapper, even to alter behavior of just one. Alternatively, you could simply subclass your DAO, and add caching to it this way. This would be a lot less boring coding upfront, but may become problematic when you do decide to change the database, or, worse, to have an option of switching implementations back and forth.)

One equally broadly used (but, in my opinion, inferior) alternative to the "factory" method is making the dao a member variable in all classes that need it:

public class App {
   GreatDao dao;
   public App(final GreatDao d) { dao = d; }
}

This way, the code that instantiates these classes needs to instantiate the DAO object (which could still use the factory) and provide it as a constructor parameter. The dependency injection frameworks I mentioned above, usually do something similar to this.

This provides all the benefits of the "factory method" approach, that I described earlier, but, as I said, is not as good in my opinion. The disadvantages here are having to write a constructor for each of your app classes, doing the same exact thing over, and over, also not being able to instantiate the classes easily when needed, and some lost readability: with a large enough code base, a reader of your code, not familiar with it, will have hard time understanding which actual implementation of the DAO is used, how it is instantiated, whether it is a singleton, a thread-safe implementation, whether it keeps state, or caches anything, how the decisions on choosing a particular implementation are made etc.

As you noted, act is not a mock, and therefore you cannot record behavior on it. You could use Mockito.spy to, well, spy (or partially mock) the act object so that you only record the behavior of secondMethod and execute the actual code for firstMethod.

Note, however, that matchers can't be used in doReturn calls regardles of how you're mocking or spying your object. A return value must be a concrete object.

class ActivityTest() {

  Activity act;

  @Before
  public void setup(){
     act = Mockito.spy(new Activity()); // Here!
  }

  @Test
  public void testFirstMethod(){

      Mockito.doReturn("someString").when(act).secondMethod();
      act.firstMethod();
      verify(act).secondMethod();
  }
} 

A slightly more elegant syntax allows you to use annotations instead of explicitly calling Mockito.spy, but it's a matter of taste really:

@RunWith(MockitoJUnitRunner.class)
class ActivityTest() {

  @Spy
  Activity act = new Activity();

  @Test
  public void testFirstMethod(){

      Mockito.doReturn("someString").when(act).secondMethod();
      act.firstMethod();
      verify(act).secondMethod();
  }
} 

Although not a direct answer to your question, however I suggest that you move away from field injection and use constructor injection instead (makes code more readable and testable).

Your code would look like:

class Patient {

  private final Syringe syringe;

  @Inject
  public Patient(Syringe syringe) {
    System.out.println("That hurt like crazy!");
  }

}

Then your test would simply be:

@RunWith(MockitoJUnitRunner.class)
class TestCase {

  @Mock
  Syringe siringeMock;

  Patient patient;

  @Before
  public void setup() {
     patient = new Patient(siringeMock);
  }

}

Update

As suggested by Erik-Karl in the comments, you could use @InjectMocks to get rid of the setup method. The solution works because Mockito will use the appropriate constructor injection (as described here). The code would then look like:

@RunWith(MockitoJUnitRunner.class)
class TestCase {

  @Mock
  Syringe siringeMock;

  @InjectMocks
  Patient patient;

}

Mockito 2 now supports final classes and methods!

But for now that's an "incubating" feature. It requires some steps to activate it which are described in What's New in Mockito 2:

Mocking of final classes and methods is an incubating, opt-in feature. It uses a combination of Java agent instrumentation and subclassing in order to enable mockability of these types. As this works differently to our current mechanism and this one has different limitations and as we want to gather experience and user feedback, this feature had to be explicitly activated to be available ; it can be done via the mockito extension mechanism by creating the file src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker containing a single line:

mock-maker-inline

After you created this file, Mockito will automatically use this new engine and one can do :

 final class FinalClass {
   final String finalMethod() { return "something"; }
 }

 FinalClass concrete = new FinalClass(); 

 FinalClass mock = mock(FinalClass.class);
 given(mock.finalMethod()).willReturn("not anymore");

 assertThat(mock.finalMethod()).isNotEqualTo(concrete.finalMethod());

In subsequent milestones, the team will bring a programmatic way of using this feature. We will identify and provide support for all unmockable scenarios. Stay tuned and please let us know what you think of this feature!

The sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) - according to the stack trace you provided, mockito got a bit confused when reporting the error. It's not really related with your problem, but anyway that's the NativeMethodAccessorImpl.invoke0 which is native (see grep code). The SpringJUnit4ClassRunner runs it, it's how it works, nothing you should care about.

Now about your real problem, as I wrote in comment, It's because Spring wraps the mock object into a proxy. If you add

System.out.println(memberRepositoryMock.getClass());

you'll see in the console that it's not the mock but some proxy there. Mockito can only stub mocks, so that's why you recieve the error.

The question might be now, how to work this around. First thing is that your test is not actually an integration test as you are trying to mock the repository instead of really test how the data access behave. In this case I would resign from using the spring-test and simply go for simple MockitoJUnitRunner.

UPDATE:

OK, now knowing that it is actually the cache to be tested, I understand you need the mocked repository to be decorated with Spring cache and that your test IS an integration test indeed.

Here's how it could be done. A little variation of mentioned frant.hartm proposal but without use of static reference. Slightly more natural I think.

@ActiveProfiles(Profiles.TEST)
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = { FullIntegrationTestConfiguration.class, BaseTestConfiguration.class, MemberCachingIntegrationTest.Config.class })
public class MemberCachingIntegrationTest {

    @Autowired
    private MemberRepository cachedRepository;

    @Autowired
    private MockProvider mockProvider;

    @After
    public void validate() {
        validateMockitoUsage();
    }

    @Test
    public void test() {
        when(mockProvider.get().findByEmail(anyString())).thenReturn("foo", "bar");

        String firstInvocation = cachedRepository.findByEmail("foo@foo.com");
        assertThat(firstInvocation, is("foo"));

        String secondInvocation = cachedRepository.findByEmail("foo@foo.com");
        assertThat(secondInvocation, is("foo"));

        verify(mockProvider.get(), times(1)).findByEmail("foo@foo.com");

        String thirdInvocation = cachedRepository.findByEmail("bar@bar.com");
        assertThat(thirdInvocation, is("bar"));

        verify(mockProvider.get(), times(1)).findByEmail("bar@bar.com");
    }

    @Configuration
    static class Config {

        private MemberRepository mockRepository = mock(MemberRepository.class);

        @Bean
        public MemberRepository cachedRepository() {
            return mockRepository;
        }

        @Bean
        public MockProvider mockProvider() {
            return new MockProvider(mockRepository);
        }

    }

    public static class MockProvider {

        private final MemberRepository repository;

        public MockProvider(MemberRepository repository) {
            this.repository = repository;
        }

        public MemberRepository get() {
            return this.repository;
        }

    }
}

Note: Repository returns Strings instead of Members for a more clear example

Mockito.doAnswer() will allow you to mock void methods and manipulate the parameters passed to it via your own closure/class implementing Answer (provided your parameters are mutable, obviously).

So given your code:

doAnswer(new Answer() {
    public Object answer(InvocationOnMock invocation) {
        Object[] args = invocation.getArguments();
        args[0] // that's the argument I want to modify
        return null;
    }})
 .when(parameterProvider).provideParameter(anyMap());

args[0] would be a Map (inspect via a debugger) and assuming it's mutable, you should be able to populate/change it within your anonymous class e.g.

((Map)args[0]).put(x, y);

You need to create a MOCK of pcUserService first, and then use that mock.

PcUserService mock = org.mockito.Mockito.mock(PcUserService.class);
when(mock.read("1")).thenReturn(pcUser);