How to use shouldFilterStackTraceOnVerifyZeroInteractions method of org.mockitousage.stacktrace.PointingStackTraceToActualInvocationTest class

In Java 8 it is even simpler than all of the above:

when(mockObject.myMethod(anyString()))
    .thenAnswer(invocation -> 
        invocation.getArgumentAt(0, String.class));

Dependency Injection

If you inject the Bar instance, or a factory that is used for creating the Bar instance (or one of the other 483 ways of doing this), you'd have the access necessary to do perform the test.

Factory Example:

Given a Foo class written like this:

public class Foo {
  private BarFactory barFactory;

  public Foo(BarFactory factory) {
    this.barFactory = factory;
  }

  public void foo() {
    Bar bar = this.barFactory.createBar();
    bar.someMethod();
  }
}

in your test method you can inject a BarFactory like this:

@Test
public void testDoFoo() {
  Bar bar = mock(Bar.class);
  BarFactory myFactory = new BarFactory() {
    public Bar createBar() { return bar;}
  };
  
  Foo foo = new Foo(myFactory);
  foo.foo();

  verify(bar, times(1)).someMethod();
}

Bonus: This is an example of how TDD(Test Driven Development) can drive the design of your code.

Actually, the problem is that each verify call is made on the same spySchool instance. Let me explain:

@Test 
public void testCountPerson() {    
    School mSchool = School.getInstance();
    School spySchool = Mockito.spy(mSchool); // a spy is created here, Mockito is listening in.
    spySchool.countPerson(true); // real method is invoked
    verify(spySchool).countIncludeTeacher(); // our spy identified that countIncludeTeacher was called

    spySchool.countPerson(false); // real method is invoked
    verify(spySchool, times(0)).countIncludeTeacher(); // our spy still identified that countIncludeTeacher was called, before it was called before
}

The thing is that in the latest verify, it fails because the countIncludeTeacher method was called on the spy before and that called was not deregistered.

You can do it using verifyNoMoreInteractions, which verifies that the object had no more interactions. You could also reset the object.

But note that this is really not recommended, quoting Mockito Javadoc:

A word of warning: Some users who did a lot of classic, expect-run-verify mocking tend to use verifyNoMoreInteractions() very often, even in every test method. verifyNoMoreInteractions() is not recommended to use in every test method. verifyNoMoreInteractions() is a handy assertion from the interaction testing toolkit. Use it only when it's relevant. Abusing it leads to overspecified, less maintainable tests. You can find further reading here.

And

Smart Mockito users hardly use this feature because they know it could be a sign of poor tests. Normally, you don't need to reset your mocks, just create new mocks for each test method.

Instead of reset() please consider writing simple, small and focused test methods over lengthy, over-specified tests. First potential code smell is reset() in the middle of the test method. This probably means you're testing too much. Follow the whisper of your test methods: "Please keep us small & focused on single behavior".

I would definitely suggest that you split this test in two: one for the true case and one for the false case.

This is a long time ago question, but here is how i did it, using Mockito spy, create a method which call the parent method in the child class:

public class Child extends Parent {
    /**
     * Shouldn't invoke protected Parent.print() of parent class.
     */
    @Override
    protected String print() {
        // some additional behavior
    return callParent();
    }

    protected callParent()
    {
      super.print();
    }

}

And in the test :

@Test
public void sould_mock_invocation_of_protected_method_of_parent_class() throws Exception {

    // Given
    Child child = Mockito.spy(new Child());
    Mockito.doReturn(null)
           .when(child)
           .callParent();
    // When
    String retrieved = child.print();

    // Then
    Mockito.verify(child, times(1)).callParent(); // verification of child method
    Assert.assertEquals(retrieved, "abc");
}

Note: this test only check we call the parent method in the child class

Adding an answer for newer versions of Mockito and Java 8

when(
   mock.method(argThat(t -> t.containsAll(Arrays.asList(IN_PROGRESS, ABANDONED, EXPIRED))))
).thenReturn(myValue);

I would try any(byte[].class)

You can use

  Mockito.doAnswer(new Answer<Void>() {
        @Override
        public Void answer(InvocationOnMock invocation) throws Throwable {
            //DO SOMETHING
            return null;
        }
    }).when(...).remove(Matchers.<String>anyVararg());

From the Javadoc:

Use doAnswer() when you want to stub a void method with generic Answer.

Stubbing voids requires different approach from Mockito.when(Object) because the compiler does not like void methods inside brackets...

Example:

    doAnswer(new Answer() {
    public Object answer(InvocationOnMock invocation) {
        Object[] args = invocation.getArguments();
        Mock mock = invocation.getMock();
        return null;
    }}).when(mock).someMethod();

See examples in javadoc for Mockito

You can not force a subclass to override a method. You can only force it to implement a method by making it abstract.

So if you can not make myMotherClass abstract you can only introduce another superclass that extends myMotherClass and delegates to the method that must be implemented:

public abstract class EnforceImplementation extends myMotherClass {

        public final void myMethod(){
             implementMyMethod();
        }

        public abstract void implementMyMethod();
}

EDIT

I found another interessting way of solving the problem in the hemcrest api that is e.g. used by mockito.

public interface Matcher<T> extends SelfDescribing {

    /**
     * Evaluates the matcher for argument <var>item</var>.
     * <p/>
     * This method matches against Object, instead of the generic type T. This is
     * because the caller of the Matcher does not know at runtime what the type is
     * (because of type erasure with Java generics). It is down to the implementations
     * to check the correct type. 
     *
     * @param item the object against which the matcher is evaluated.
     * @return <code>true</code> if <var>item</var> matches, otherwise <code>false</code>.
     *
     * @see BaseMatcher
     */
    boolean matches(Object item);

    /**
     * This method simply acts a friendly reminder not to implement Matcher directly and
     * instead extend BaseMatcher. It's easy to ignore JavaDoc, but a bit harder to ignore
     * compile errors .
     *
     * @see Matcher for reasons why.
     * @see BaseMatcher
     */
    void _dont_implement_Matcher___instead_extend_BaseMatcher_();
}

The interface specifies a method _dont_implement_Matcher___instead_extend_BaseMatcher_. Of course it does not prevent others from implementing the Matcher interface, but it guides the developer in the right direction.

And the BaseMatcher class implements the _dont_implement_Matcher___instead_extend_BaseMatcher_ method as final

public final void _dont_implement_Matcher___instead_extend_BaseMatcher_() {
    // See Matcher interface for an explanation of this method.
}

Finally I think that this is a design problem, because the BaseMatcher obviouosly implements logic that every Matcher should implement. Thus it would have been better to make the Matcher an abstract class and use a template method.

But I guess they did it because it was the best compromise between bytecode compatibility and new features.

It seems that you can define dependencies per Play framework ID, similar to how you can define settings for a specific ID in the application.conf file. To do this, you need to add an additional id attribute to your dependency definition.

For example, if you wanted to only include mockito-core in environments with a framework ID of test, your dependencies.yml file would look like the following:

require:
    - org.mockito -> mockito-core 1.8.5:
        id: test

You can get this to work when using a single machine as well, although you have to be a bit more deliberate about it. To test with your test-only dependencies, you'd define your dependency with id: test and then run:

play dependencies --%test --sync
play test

Then, to switch back to production, you'd run:

play dependencies --sync
play run

The downside is that you have to remember to sync your dependencies every time you switch between test and production modes, but I think that this is currently the best you can do if you want to make sure that the dependency is only on the classpath when in test mode.