How to use shouldVerifyLastInvocation method of org.mockitousage.verification.BasicVerificationInOrderTest class

You can just write

verify(service).perform((Collection<String>) Matchers.argThat(contains("a", "b")));

From the compiler's point of view, this is casting an Iterable<String> to a Collection<String> which is fine, because the latter is a subtype of the former. At run time, argThat will return null, so that can be passed to perform without a ClassCastException. The important point about it is that the matcher gets onto Mockito's internal structure of arguments for verification, which is what argThat does.

You don't.

When Unittesting you verify public observable behavior that means: What results are returned depending on the input and how does the unit communicate with its dependencies.

The variable 'p' is an implementation detail that you do not verify. This is because in may change without changing the units behavior and you don't want to change the test in that case.

From the Mockito FAQ:

What are the limitations of Mockito

• Cannot mock final methods - their real behavior is executed without any exception. Mockito cannot warn you about mocking final methods so be vigilant.

Don't mock the InputStream. Instead, transform the String to an array of bytes using the getBytes() method. Then create a ByteArrayInputStream with the array as input, so that it returns the String when consumed, each byte at a time. Next, create a ServletInputStream that wraps a regular InputStream like the one from Spring:

public class DelegatingServletInputStream extends ServletInputStream {

    private final InputStream sourceStream;


    /**
     * Create a DelegatingServletInputStream for the given source stream.
     * @param sourceStream the source stream (never <code>null</code>)
     */
    public DelegatingServletInputStream(InputStream sourceStream) {
        Assert.notNull(sourceStream, "Source InputStream must not be null");
        this.sourceStream = sourceStream;
    }

    /**
     * Return the underlying source stream (never <code>null</code>).
     */
    public final InputStream getSourceStream() {
        return this.sourceStream;
    }


    public int read() throws IOException {
        return this.sourceStream.read();
    }

    public void close() throws IOException {
        super.close();
        this.sourceStream.close();
    }

}

and finally, the HttpServletRequest mock would return this DelegatingServletInputStream object.

The following suggestion let's you test abstract classes without creating a "real" subclass - the Mock is the subclass.

use Mockito.mock(My.class, Mockito.CALLS_REAL_METHODS), then mock any abstract methods that are invoked.

Example:

public abstract class My {
  public Result methodUnderTest() { ... }
  protected abstract void methodIDontCareAbout();
}

public class MyTest {
    @Test
    public void shouldFailOnNullIdentifiers() {
        My my = Mockito.mock(My.class, Mockito.CALLS_REAL_METHODS);
        Assert.assertSomething(my.methodUnderTest());
    }
}

Note: The beauty of this solution is that you do not have to implement the abstract methods, as long as they are never invoked.

In my honest opinion, this is neater than using a spy, since a spy requires an instance, which means you have to create an instantiatable subclass of your abstract class.

It should be something like

@RunWith(SpringJUnit4ClassRunner.class)
public class aTest () {

    @Mock
    private B b;

    @Mock
    private C c;

    @Autowired
    @InjectMocks
    private A a;

}

If you want D to be Autowired dont need to do anything in your Test class. Your Autowired A should have correct instance of D. Also i think you need to use SpringJUnit4ClassRunner for Autowiring to work, with contextConfiguration set correctly. Because you are not using MockitoJunitRunner you need to initialize your mocks yourself using

MockitoAnnotations.initMocks(java.lang.Object testClass)

This is a bug that occurs when you use JUnit 4.12 and PowerMock < 1.6.1. The problem is solved in PowerMock 1.6.1. Please update your dependencies accordingly

testCompile 'junit:junit:4.12',
            'org.powermock:powermock-core:1.6.1',
            'org.powermock:powermock-module-junit4:1.6.1',
            'org.powermock:powermock-api-mockito:1.6.1'

If you cannot upgrade PowerMock then you can use JUnit 4.11.

testCompile 'junit:junit:4.11',
            'org.powermock:powermock-core:1.5.6',
            'org.powermock:powermock-module-junit4:1.5.6',
            'org.powermock:powermock-api-mockito:1.5.6'

Could you please add further lines of the stacktrace, which uncover more details about the problem.

Declare the exception in the test method.

public void testAddUser() throws ServiceException {
...
}

In JUnit, Parameterized tests use a special runner that ensure that the test is instantiated multiple times, so each test method is called multiple times. Mockito is a tool for writing specific unit tests, so there is no built-in ability to run the same test multiple times with different Mockito expectations.

If you want your test conditions to change, your best bet is to do one of the following:

• Parameterize your test using JUnit, with a parameter for the mock inputs you want;
• Run a loop of different parameters in your test, which unfortunately avoids the "test one thing per method" philosophy
• Extract a method that actually performs the test, and create a new @Test method for each mock you want.

Note that there's no prohibition on using mock objects as @Parameterized test parameters. If you're looking to parameterize based on mocks, you can do that, possibly creating the mock and setting the expectations in a static method on the test.

Note about runners: This Parameterized test runner conflicts with Mockito's MockitoJUnitRunner: Each test class can only have one runner. You'll want to switch to @Before and @After methods or a Mockito JUnit4 rule for your setup, if you use them both.

As an example, compressed from a different answer that explains more about Parameterized runners versus JUnit rules and lifting from the JUnit4 Parameterized Test doc page and MockitoRule doc page:

@RunWith(Parameterized.class)
public class YourComponentTest {
    @Rule public MockitoRule rule = MockitoJUnit.rule();
    @Mock YourDep mockYourDep;

    @Parameters public static Collection<Object[]> data() { /* Return the values */ }

    public YourComponentTest(Parameter parameter) { /* Save the parameter to a field */ }

    @Test public void test() { /* Use the field value in assertions */ }
}