How to use should_pass_Error method of org.mockito.internal.stubbing.answers.AbstractThrowsExceptionTest class

According to the Mockito_Maven page on the PowerMock wiki, use this:

<properties>
    <powermock.version>1.6.6</powermock.version>
</properties>
<dependencies>
   <dependency>
      <groupId>org.powermock</groupId>
      <artifactId>powermock-module-junit4</artifactId>
      <version>${powermock.version}</version>
      <scope>test</scope>
   </dependency>
   <dependency>
      <groupId>org.powermock</groupId>
      <artifactId>powermock-api-mockito</artifactId>
      <version>${powermock.version}</version>
      <scope>test</scope>
   </dependency>
</dependencies>

powermock-api-support seems to be "utility classes only", where you still need the core libraries provided in powermock-module-junit4.

JUnit creates a new instance of test class each time it runs a new test method and runs @Before method each time it creates a new test class. You can easily test it:

@Before
public void setup() {
    System.out.println("setup");
    when(myMock.myMethod()).thenReturn("hello");
}

And MockitoJUnitRunner will create a new MyMock mock instance for every test method.

Class self-use isn't necessarily a problem: I'm not yet convinced that "it should only test the deleteOrganization method" for any reason other than personal or team style. Though it's helpful to keep deleteUser and deleteOrganization into independent and isolated units, that isn't always possible or practical—especially if the methods call one another or rely on a piece of common state. The point of testing is to test the "smallest testable unit"—which does not require that methods are independent or that they can be tested independently.

You have a few choices, depending on your needs and how you expect your codebase to evolve. Two of these are from your question, but I'm restating them below with advantages.

• Test black-box.

  If you were to treat MyClass as an opaque interface, you likely wouldn't expect or require deleteOrganization to repeatedly call deleteUser, and you can imagine the implementation changing such that it doesn't do so. (Maybe a future upgrade would have a database trigger take care of a cascading delete, for instance, or a single file deletion or API call might take care of your organizational delete.)

  If you treat deleteOrganization's call to deleteUser as a private method call, then you're left testing MyClass's contract and not its implementation: Create an organization with some users, call the method, and check that the organization is gone and that the users are too. It may be verbose, but it is the most correct and flexible test.

  This may be an attractive option if you expect your MyClass to change drastically, or to get a whole new replacement implementation.

• Split the class horizontally into OrganizationDeleter and UserDeleter.

  To make the class more "SRPy" (i.e. conforming better to the Single Responsibility Principle), as the Mockito documentation alludes, you'd see that deleteUser and deleteOrganization are independent. By separating those out into two different classes, you could have the OrganizationDeleter accept a mock UserDeleter, eliminating your need for a partial mock.

  This may be an attractive option if you expect the user-deleting business logic to vary, or you want to expect to write another UserDeleter implementation.

• Split the class vertically into MyClass and MyClassService/MyClassHelper.

  If there's enough difference between the low-level infrastructure and high-level calls, you may want to separate them out. MyClass would keep deleteUser and deleteOrganization, perform whatever preparation or validation steps are needed, and then make a few calls to the primitives in MyClassService. deleteUser would probably be a straightforward delegate, whereas deleteOrganization could call the service without invoking its neighbor.

  If you have enough low-level calls to warrant this extra separation, or if MyClass deals with both high-level and low-level concerns, this may be an attractive option—especially if it's a refactor that's occurred to you before. Be careful to avoid the pattern of baklava code, though (too many thin, permeable layers than you could ever keep track of).

• Continue using partial mocks.

  Though this does leak the implementation detail of internal calls, and this does go against the Mockito warning, on balance partial mocks could provide the best pragmatic choice. If you have one method calling its sibling multiple times, it may not be well-defined whether the inner method is a helper or a peer, and a partial mock would save you from having to make that label.

  This may be an attractive option if your code has an expiration date, or is experimental enough not to warrant a full design.

(Side note: It's true that unless MyClass is final it is open to subclassing, which is part of what makes partial mocks possible. If you were to document that deleteOrganization's general contract involved multiple calls to deleteUser, then it would be entirely fair game to create a subclass or partial mock. If it's not documented, then it's an implementation detail, and should be treated as such.)

You have two methods with the same name and return type, each with one parameter. So anyObject() matches both of them. That's why you get the batchWriteItem is ambiguous message.

You could use Mockito.any(Class<T> type) and Mockito.anyMapOf(Class<K> keyClazz, Class<V> valueClazz) to distinguish between them.

Docs for reference: any, anyMapOf

Using void reset(T... mocks) will reset all stubbings on the mocks. If you just need to reset the invocation counts for subsequent verifications, use void clearInvocations(T... mocks).

Mockito supports this out of the box:

public class ProductionCodeClassTest {

    @Mock
    private DependencyClass dependency;

    @InjectMocks
    private ProductionCodeClass testedInstance;

    @Before
    public void setUp() {
        testedInstance = new ProductionCodeClass();
        MockitoAnnotations.initMocks(this);
    }

}

The @InjectMocks annotation will trigger injection of classes or interfaces mocked in the test class, in this case DependencyClass:

Mockito tries to inject by type (using name in case types are the same). Mockito does not throw anything when injection fails - you will have to satisfy the dependencies manually.

Here, I am also using the @Mock annotation instead of calling mock(). You could still use mock(), but I prefer using annotations.

As a side note, there are reflection tools available, which supports the functionality you implemented in TestSupport. One such example is ReflectionTestUtils.

---

Perhaps better still is to use constructor injection:

public class ProductionCodeClass {

    private final DependencyClass dependency;

    @Inject
    public ProductionCodeClass(DependencyClass dependency) {
        this.dependency = dependency;
    }
}

The main advantage here is that it is clear what classes the class depends on, and that it cannot easily be constructed without providing all the dependencies. Also, it allows the injected class to be final.

By doing this, @InjectMocks is not necessary. Instead, just create the class by providing the mock as a parameter to the constructor:

public class ProductionCodeClassTest {

    @Mock
    private DependencyClass dependency;

    private ProductionCodeClass testedInstance;

    @Before
    public void setUp() {
        MockitoAnnotations.initMocks(this);
        testedInstance = new ProductionCodeClass(dependency);
    }

}

New feature added to Mockito makes this even easier,

ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
verify(mock).doSomething(argument.capture());
assertEquals("John", argument.getValue().getName());

Take a look at Mockito documentation

---

In case when there are more than one parameters, and capturing of only single param is desired, use other ArgumentMatchers to wrap the rest of the arguments:

verify(mock).doSomething(eq(someValue), eq(someOtherValue), argument.capture());
assertEquals("John", argument.getValue().getName());

From what I read on "Issue 53" of mockito (https://code.google.com/p/mockito/issues/detail?id=53) , my code was experiencing a problem due to the validation framework involved in Mockito. Precisely the following code was causing the exception per se.

private ConstantNode getConstantNode(NumericalValue value){
    ConstantNode node = Mockito.mock(ConstantNode.class);
    Mockito.when(node.evaluate()).thenReturn(value);
    Mockito.when(node.toString()).thenReturn(value.toString());
    return node;
}

If you remember from my code, the parameter value is ALSO A MOCK, so that when value.toString() is called on the thenReturn(), I believe (and someone please correct me if I am wrong) that the validation framework is triggered and makes sure that every "when" has had its thenReturn() called/validated/etc. So that if this happenes, the Mockito.when(node.toString()).thenReturn(value.toString() will not be validated because it hasn´t returned from the valute.toString(), which started the whole "validate everything" chain.

How I fixed it:

private ConstantNode getConstantNode(NumericalValue value){
    ConstantNode node = Mockito.mock(ConstantNode.class);
    Mockito.when(node.evaluate()).thenReturn(value);

    String numberToString = value.toString();

    Mockito.when(node.toString()).thenReturn(numberToString);
    return node;
}

This way, it can be validated. I find this a complete code smell because I will literally have to leave a comment that explains why I am using a seemingly useless intermediate variable in the code.

Thanks for the help.

The MockitoExtension is published in the mockito-junit-jupiter artifact.

You can add a dependency on it as follows.

Maven

<dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-junit-jupiter</artifactId>
  <version>2.27.0</version>
  <scope>test</scope>
</dependency>

Gradle

testCompile 'org.mockito:mockito-junit-jupiter:2.27.0'

Further Resources

• https://github.com/mockito/mockito/issues/1517#issuecomment-429621891
• https://search.maven.org/artifact/org.mockito/mockito-junit-jupiter/2.27.0/jar