Develop Reference

Mocking void unit tests with Mockito

Having had many issues in unit testing my application please help address my simplest issue - mocking void methods, per a few stack overflow articles and common references in articles. My Java code in a JBPM application WorkItemHandler follows the pattern of
public class EmailNotificationWorkItemHandler() extends AbstractLogOrThrowWorkItemHandler {
private static Utils utils = new Utils() ;
public void executeWorkItem(WorkItem workItem, WorkItemManager manager) {
if (<condition>) {
utils.insertAmsErrors(<param>, <param>, <param>, <param>, <param>);
return;
}
....
try {
RequiredParameterValidator.validate(this.getClass(), workItem);
...
}
I have been trying to stub Utils and its insertAmsErrors method to test RequiredParameterValidator.validate used later in executeWorkItem. The references imply that the void call to utils and its insertAmsErrors method could be a very basic stub of
Utils mockUtils = mock(Utils.class);
doAnswer(new Answer<Void>() {
public Void answer(InvocationOnMock invocation) {
Object[] args = invocation.getArguments();
//Mock mock = (Mock) invocation.getMock(); Doesn't solve NPE
return null;
}
}).when(mockUtils).insertAmsErrors(any(), any(), any(), any(), any()); // NPE here
but the stub throws a null pointer exception at "NPE here". Utils.insertAmsErrors signature is
public void insertAmsErrors(String id, ErrorCode error, String errorMsg,
StackTraceElement [] stackTrace, long processId)
I also considered using a spy, per another answer in the same posting, but my unit test is not calling insertAmsErrors on an instance of Utils, but rather executeWorkItem in EmailNotificationWorkItemHandler is making such a call.
How should I correctly mock the Utils class and its insertAmsErrors method so that I can test RequiredParameterValidator.validate in executeWorkItem?

The problem is not related to the fact that you're mocking a void method. The problem lies in your usage of the any() method.
when(mockUtils).insertAmsErrors(any(), any(), any(), any(), any());
The 5th required parameter is of type long and for this reason you should use the dedicated anyLong() method for it instead. This applies to all primitive types: anyInt() for int parameters, anyBoolean() for boolean parameters and so on...
The reason behind this is that Mockito's any() method returns null by design, inducing a NPE when there is an attempt to unbox it. See this related answer for more details about it.
(On a side note) Another potential problem could rise by the fact that your utils field is static, private and with an hardcoded dependency. This is not a good target for stubbing and you should probably rethink this by making, for example, the field non-static and then injecting the dependency.
public class EmailNotificationWorkItemHandler() extends AbstractLogOrThrowWorkItemHandler {
private Utils utils;
public EmailNotificationWorkItemHandler(Utils utils){
this.utils = utils;
}
...
}
This way you can pass the mocked object during your unit tests.

Mockito to throw exception when calling super method [duplicate]

I'm using Mockito in some tests.
I have the following classes:
class BaseService {
public void save() {...}
}
public Childservice extends BaseService {
public void save(){
//some code
super.save();
}
}
I want to mock only the second call (super.save) of ChildService. The first call must call the real method. Is there a way to do that?

If you really don't have a choice for refactoring you can mock/stub everything in the super method call e.g.
class BaseService {
public void validate(){
fail(" I must not be called");
}
public void save(){
//Save method of super will still be called.
validate();
}
}
class ChildService extends BaseService{
public void load(){}
public void save(){
super.save();
load();
}
}
#Test
public void testSave() {
ChildService classToTest = Mockito.spy(new ChildService());
// Prevent/stub logic in super.save()
Mockito.doNothing().when((BaseService)classToTest).validate();
// When
classToTest.save();
// Then
verify(classToTest).load();
}

No, Mockito does not support this.
This might not be the answer you're looking for, but what you're seeing is a symptom of not applying the design principle:
Favor composition over inheritance
If you extract a strategy instead of extending a super class the problem is gone.
If however you are not allowed to change the code, but you must test it anyway, and in this awkward way, there is still hope. With some AOP tools (for example AspectJ) you can weave code into the super class method and avoid its execution entirely (yuck). This doesn't work if you're using proxies, you have to use bytecode modification (either load time weaving or compile time weaving). There are be mocking frameworks that support this type of trick as well, like PowerMock and PowerMockito.
I suggest you go for the refactoring, but if that is not an option you're in for some serious hacking fun.

Consider refactoring the code from ChildService.save() method to different method and test that new method instead of testing ChildService.save(), this way you will avoid unnecessary call to super method.
Example:
class BaseService {
public void save() {...}
}
public Childservice extends BaseService {
public void save(){
newMethod();
super.save();
}
public void newMethod(){
//some codes
}
}

I found a way to suppress the superclass method using PowerMockito. 3 simple steps need for this
Use PowerMockito.suppress method and MemberMatcher.methodsDeclaredIn method to supress parent class method
Second add Parent class in #PrepareForTest
Run your test class with PowerMock ie add #RunWith(PowerMockRunner.class) above your test class.
#RunWith(PowerMockRunner.class)
#PrepareForTest({BaseService.class})
public class TestChildService(){
#Spy
private ChildService testChildServiceObj = Mockito.spy(new ChildService());
#Test
public void testSave(){
PowerMockito.suppress(MemberMatcher.methodsDeclaredIn(BaseService.class));
//your further test code
testChildServiceObj.save();
}
}
Note: This will work only when the superclass method does not return anything.

Maybe the easiest option if inheritance makes sense is to create a new method (package private??) to call the super (lets call it superFindall), spy the real instance and then mock the superFindAll() method in the way you wanted to mock the parent class one. It's not the perfect solution in terms of coverage and visibility but it should do the job and it's easy to apply.
public Childservice extends BaseService {
public void save(){
//some code
superSave();
}
void superSave(){
super.save();
}
}

create a package protected (assumes test class in same package) method in the sub class that calls the super class method and then call that method in your overridden sub class method. you can then set expectations on this method in your test through the use of the spy pattern. not pretty but certainly better than having to deal with all the expectation setting for the super method in your test

Even if i totally agree with iwein response (
favor composition over inheritance
), i admit there are some times inheritance seems just natural, and i don't feel breaking or refactor it just for the sake of a unit test.
So, my suggestion :
/**
* BaseService is now an asbtract class encapsulating
* some common logic callable by child implementations
*/
abstract class BaseService {
protected void commonSave() {
// Put your common work here
}
abstract void save();
}
public ChildService extends BaseService {
public void save() {
// Put your child specific work here
// ...
this.commonSave();
}
}
And then, in the unit test :
ChildService childSrv = Mockito.mock(ChildService.class, Mockito.CALLS_REAL_METHODS);
Mockito.doAnswer(new Answer<Void>() {
#Override
public Boolean answer(InvocationOnMock invocation)
throws Throwable {
// Put your mocked behavior of BaseService.commonSave() here
return null;
}
}).when(childSrv).commonSave();
childSrv.save();
Mockito.verify(childSrv, Mockito.times(1)).commonSave();
// Put any other assertions to check child specific work is done

You can do this with PowerMockito and replace behavior only of the parent class method with continuing testing the child's class method. Even when the method is returning some value, lets say a string, you can do something like this:
#RunWith(PowerMockRunner.class)
#PrepareForTest({ BaseService.class })
public class TestChildService() {
private BasicService basicServiceObj;
private ChildService testee;
#Before
public void init() throws Exception {
testee = new ChildService();
basicServiceObj = PowerMockito.spy(new BaseService());
PowerMockito.doReturn("Result").when(basicServiceObj, "save", ... optionalArgs);
}
#Test
public void testSave(){
testee.save();
}
}
If you are returning nothing (void) then instead of doReturn you can use doNothing. Add some optionalArgs if the method have some arguments, if not, then skip that part.

The reason is your base class is not public-ed, then Mockito cannot intercept it due to visibility, if you change base class as public, or #Override in sub class (as public), then Mockito can mock it correctly.
public class BaseService{
public boolean foo(){
return true;
}
}
public ChildService extends BaseService{
}
#Test
#Mock ChildService childService;
public void testSave() {
Mockito.when(childService.foo()).thenReturn(false);
// When
assertFalse(childService.foo());
}

There is simple approach that works for most of cases. You can spy your object and stub the method you want to mock.
Here is an example:
MyClass myObjectSpy = Mockito.spy(myObject);
org.mockito.Mockito.doReturn("yourReturnValue").when(mySpyObject).methodToMock(any()..);
So, when you test your object, you can use myObjectSpy and when methodToMock is called, it will overwrite the normal behavior by a mock method.
This code for a method with return. In case you have a void method you can use doNothing instead.

JMockit: Overriding #Mocked class

I have an internal StreamGobbler class that has 7 methods in it.
I'm looking for a quick way to mock all the methods by default, but override one method named getOutput() (e.g. Partial Mocking).
(full code not shown for clarity)
public class StreamGobbler extends Thread
{
public String getOutput()
public void run()
}
What I would like is to use something like the #Mocked annotation in combination with MockUp to partially mock the getOutput method, but retain all the "default" mocking code on all the other methods. In the docs on partial mocking, it makes the point that if you use MockUp, all non #Mock methods retain their normal functionality. Sometimes that is great, but that isn't what I want in this case.
This is similar to the question JMockit: #Mocke and MockUp combination in the same test, but I can't get away with just looking at method counts.
If I have a test setup like this:
#Test
public void execute(#Mocked StreamGobbler sg)
{
new MockUp<StreamGobbler>()
{
String type = null;
#Mock
void $init(String type)
{
this.type = type;
}
#Mock
String getOutput()
{
if ("OUTPUT".equals(type))
{
return "test output";
}
else
{
return "";
}
}
}
}
I get this error java.lang.IllegalArgumentException: Class already mocked
If I try to add the #Override annotation in the MockUp, it doesn't help (and Eclipse complains about it)
What is the best way to handle this? Use a static class outside this test method?
Using JMockit 1.17, and TestNG
In summary, how do I get every method in StreamGobbler mocked (as with #Mocked), but partially override one method (without manually doing it myself inside the MockUp?)

Full example code which meets the given constraints:
public static class StreamGobbler extends Thread {
public StreamGobbler(String type) {}
public String getOutput() { return null; }
#Override public void run() {}
}
public static class TestedClass {
public String doSomething() throws InterruptedException {
StreamGobbler sg1 = new StreamGobbler("OUTPUT");
sg1.start();
StreamGobbler sg2 = new StreamGobbler("ERROR");
sg2.start();
sg1.join(5000);
sg2.join(5000);
String output1 = sg1.getOutput();
String output2 = sg2.getOutput();
return output1 + '|' + output2;
}
}
#Test
public void useStreamGobbler(#Mocked StreamGobbler sg) throws Exception {
new Expectations() {{
new StreamGobbler("OUTPUT").getOutput(); result = "test output";
new StreamGobbler("ERROR").getOutput(); result = "";
}};
String output = new TestedClass().doSomething();
assertEquals("test output|", output);
}

Firstly, since you are creating an anonymous subclass of the MockUp class, using the #Override annotation would certainly be inappropriate. Those methods that you are providing do not belong to the MockUp class, but the generic you are providing.
Later on during runtime, (through some impressive process (based on what I read here, I'm assuming AOP)) the instance you create in this class will then use your provided method signatures instead of its own.
After reading the API on the Mock class more thoroughly as well as getting some information from JMockit's Getting Started page, I think you're issue lies in a different area entirely. If you have other test methods, they will be interfering with this method.
The error you are getting is saying: "There is already an instance of MockUp declared for the type StreamGobbler, and by calling the Mocked annotation in this test method's parameters and attempting to declare another instance of MockUp with the same generic, you are violating a JMockit stipulation."
I would check to see if you are creating an actual MockUp of StreamGobbler outside of the test method and if so (1) if you want to use it, don't redeclare another instance of MockUp in the method but continue to use the Mocked annotation or (2) if you do not want to use it and you want to re-declare a new instance of MockUp wrapping StreamGobbler, do not use the Mocked annotation in the test method's parameters but keep the MockUp instantiation.

Is it possible to mock a single method in an already existing object?

For an integration test, I need to mock a specific method in a java service client without destroying the rest of the information in it. It has no self-constructor, so a solution like this is out of the question:
private DBClient mockClient = new DBClient(alreadyExistingClient){
#Override
void deleteItem(Item i){
//my stuff goes here
}
};
Is there a way to mock the deleteItem method such that the credentials, endpoints, etc... are preserved in an existing DBClient object?
edit: mockito is not available for use in this case

You can use a Dynamic Proxy to intercept any method invocation you want, so you can decide between invoking the real method or do whatever you want instead.
This is an example of how to intercept the method Set.add(), you can do exactly the same for deleteItem()
package example.dynamicproxy;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.util.Set;
public class SetProxyFactory {
public static Set<?> getSetProxy(final Set<?> s) {
final ClassLoader classLoader = s.getClass().getClassLoader();
final Class<?>[] interfaces = new Class[] {Set.class};
final InvocationHandler invocationHandler = new InvocationHandler() {
#Override
public Object invoke(final Object proxy, final Method method, final Object[] args) throws Throwable {
if (method.getName().equals("add")) {
System.out.println("add() intercepted");
// do/return whatever you want
}
// or invoke the real method
return method.invoke(s, args);
}
};
final Object proxy = Proxy.newProxyInstance(classLoader, interfaces, invocationHandler);
return (Set<?>) proxy;
}
}

You could go lo-fi and create a sub-class of the DBClient class. To this subclass, pass the instance of DBClient you want to mock.
Use composition inside the sub-class, and delegate all method calls to the original DBClient, all except the one you want to mock. Add your mock implementation to the method you want.
This is not as reusable as a mocking framework, but should work.
DBClient mockDbClient = new DBClient() {
private DBClient dbClientDelegate;
public void setDelegate(DBClient dbClient) {
dbClientDelegate = dbClient;
}
//override all methods.
//delegate to the corresponding method of the dbClientDelegate instance
//overide the method you want to mock, add asserts for method arguments
//return mock data as appropriate
}
mockDbClient.setDelegate(preinstantiatedDbClient);
//inject mockDbClient to test class
//call test class / method
Hope this helps.

In Mockito 2+ you can use spy feature for this purpose:
PrintStream realSystemOut = System.out;
realSystemOut.println("XXX");
PrintStream mockedSystemOut = Mockito.spy(realSystemOut);
Mockito.doNothing().when(mockedSystemOut).println(Mockito.anyString());
mockedSystemOut.println("YYY");
Output:
XXX

JUnit custom runner not working?

I´m trying to write a custom Runner which simply does the Tests in a random order. The runner:
public class TestClassRunnerForParameters extends BlockJUnit4ClassRunner {
public TestClassRunnerForParameters(Class<?> type) throws Exception {
super(type);
}
protected java.util.List<org.junit.runners.model.FrameworkMethod> computeTestMethods() {
java.util.List<org.junit.runners.model.FrameworkMethod> methods = super
.computeTestMethods();
Collections.shuffle(methods);
return methods;
}
}
Now this works fine if it is not a parameterized Test. Is it possible to do this using a Parameter Test? Implementing the Parameterized interface?

I'd say the error is pretty self-descripting:
Custom runner class TestClassRunnerForParameters should have a public constructor with signature TestClassRunnerForParameters(Class testClass)
Your class has no constructor with that signature. Its only constructor has parameters Class<?> type, List<Object[]> parameterList and int i. You should remove the latter two arguments. Plus, that constructor isn't public; you should add public in front of it.
Besides, if you're trying to build parametrised tests, you might be intested in the org.junit.runners.Parameterized runner, as it does exactly that. Here's a good tutorial.

Simply add a constructor, (as advised):
public TestClassRunnerForParameters(Class testClass) {
...
}
And have it delegate to your constructor. Your constructors should be public in this case, as JUnit/Surefire is using reflection.