We Keep Coding

Mocking public method inside a private method

I have a class like below:
public class ClassOne {
public function1(input, output, context) {
//some implementation
private function2(List, String, String);
}
private void function2(List, String, String){
Class2 class2 = new Class2();
String value = class2.method1(string, string);
}
}
public Class2 {
public String method2(string, string) {
//some implementation
return string;
}
}
I am writing Unit test for ClassOne using Mockito and PowerMockito and would like to mock the call to class2 and do not want to actually call method body for method2. How can I achieve this?
I tried Mockito.mock and PowerMockito.spy the class and when(class2.method2).thenReturn() and doReturn().when(class2).method2(); but everything calls the method body when I do classOne.function1. I have spied the ClassOne.

It would be really helpful if you would have also provided your non working Unit Tests. On the other hand I'm pretty sure the problem isn't there anyway :)
Your problem is not that Mockito & PowerMockito are not working.
The real problem is in the dependency of you classes. Or to be more specific the way your classes handle this dependency.
In General it is not a good idea to instantiate the dependency (Class2) in the place it is needed (ClassOne). As you can see right now it makes testing pretty hard.
It would be better to pass the dependency into the class that needs it.
This is called Dependency Injection (DI).
In your example you would pass an object of Class2 into the constructor of ClassOne. The Code would look something like that:
public class ClassOne {
private final Class2 class2;
public ClassOne(Class2 class2) {
this.class2 = class2;
}
...
private void function2(List, String, String){
String value = class2.method1(string, string);
}
}
As you can see you simply pass an instance of your dependency and use this one instead of creating it on your own.
In your Unit Test you are now able to pass a Mock of Class2 into your Class1 object which will then be used.

PowerMockito doesn't mock the new instance called in the tested class

I have the following class where, in the constructor, I call another constructor to build a field of the class:
public class ClassIWantToTest {
private ClassIWantToMock anotherClass;
public ClassIWantToTest() {
//some stuff
anotherClass = new ClassIWantToMock(); //<-- call constructor to build the field
//some other stuff
}
}
When I test the class ClassIWantToTest, I want to mock the instance of ClassIWantToMock.
Hence, I've set up my test as follows:
#RunWith(PowerMockRunner.class)
#PrepareForTest(ClassIWantToMock.class)
public class ClassIWantToTest_Test {
#Test
public void myFirstTest() {
ClassIWantToMock myMock = PowerMockito.mock(ClassIWantToMock.class);
PowerMockito.whenNew(ClassIWantToMock.class).withAnyArguments().thenReturn(myMock);
ClassIWantToTest test = new ClassIWantToTest(); //<-- not mocked
}
}
However, in the last line of code in the test (where I make a new of the class I want to test), the constructor of ClassIWantToMock is still called.
I've searched other examples on Stack Overflow (and in documentation), but it seems that it should be done like this. What am I forgetting/doing wrong?

It was indeed a simple mistake. If the class ClassIWantToMock is initialized inside ClassIWantToTest, then also ClassIWantToTest should be prepared for test.
I replaced this:
#PrepareForTest(ClassIWantToMock.class)
with this:
#PrepareForTest({ClassIWantToTest.class,ClassIWantToMock.class})
... and it worked fine.

how to mock with mockito

I have a method in my MainActivity (Android) and I want to mock the A instance :
public void some_method() {
A a = new A();
....
}
so I created a kind of factory class as such
public class SomeFactory(){
// some constructor
public A populateWithParameter(Parameter parameter){
return new A(parameter)
}
}
and the method above turns into
public void some_method(SomeFactory someFactory) {
A a = someFactory.populateWithParameter(parameter);
a.method_call()
....
}
I tried this
#Mock
SomeFactory someFactory;
public void testSomeMethod() throws Exception {
SomeFactory someFactory = new SomeFactory();
when(someFactory.populateWithParameter(
some_parameter)).thenReturn(null);
mainActivity.some_method(someFactory);
...
}
but I get this error message
org.mockito.exceptions.misusing.MissingMethodInvocationException:
when() requires an argument which has to be 'a method call on a mock'.
For example:
when(mock.getArticles()).thenReturn(articles);

You are not mocking your factory. Also, wrong method call.
Do this instead.
SomeFactory someFactory = mock(SomeFactory.class)
when(someFactory.populateWithParameter(
some_parameter)).thenReturn(null);
mainActivity.some_method(someFactory);
UPDATE
Your code has changed so for completeness this is what your test should look like. In the updated code above, you were overwriting your mock with a real object. Assuming your objects are correctly set up. Notice the different syntax for providing a return object. I think this is more readable.
#Mock SomeFactory mockFactory;
#Before
public void setUp() {
MockitoAnnotations.initMocks(this); // set up annotated mocks
}
#Test
public void testSomeMethod() {
A subject = new A();
doReturn(subject).when(mockFactory)
.populateWithParameter(any(Parameter.class));
main_activity.some_method(mockFactory);
verify(mockFactory,times(1)).populateWithParameter(any(Parameter.class));
}
Best Practices
When naming methods and variables, use camelCase. So main_activity becomes MainActivity, some_method becomes SomeMethod.

You need a way to overwrite the instance of A from your test. Typically this is done using an injection framework. For a simple case, you can make the field under test protected (assuming the test class is in the same package as the class under test).
The error you are seeing comes interacting with a "real" object as if it was a mock.
In this case SomeFactory is a real object so it cannot be when()ed

From the point of view of response of #DiscoS2, there is indeed an issue with this declaration
MockitoAnnotations.initMocks(this);
You should use instead SomeFactory someFactory = mock(SomeFactory.class) and then follow the updated response of #DiscoS2

Test if another method was called

So I'm sure there is something like this out there but I have been searching for an hour and haven't found exactly what I am looking for. say I have a class that looks like this:
public class MyClass
{
public void myMethod(boolean shouldCallOtherMethod)
{
if(shouldCallOtherMethod)
{
otherMethod();
}
}
public void otherMethod()
{
System.out.println("Called");
}
}
How do I make something like this work?
#Test
public void shouldCallMethod()
{
MyClass myClass = new MyClass();
myClass.myMethod(true)
// verify myClass.otherMethod method was called
}

Using Mockito, you can do spying on real objects like this:
import org.junit.Test;
import static org.mockito.Mockito.*;
public class MyClassTest {
#Test
public void otherMethodShouldBeCalled() {
MyClass myClass = new MyClass();
MyClass spy = spy(myClass);
spy.myMethod(true);
verify(spy).otherMethod();
}
}
There are some gotchas, so take a look at the relevant documentation as well.

Suppose MokeysClass has a constructor declared like this, where Foo is some other class.
public MokeysClass(String name, int counter, Foo myFoo)
I would write my test like this.
#RunWith(MockitoJUnitRunner.class)
public class TestArray {
#Mock
private Foo mockMyFoo;
private String nameToInject = "Mokey";
private int counterToInject = 42;
#Spy
private MokeysClass toTest = new MokeysClass(nameToInject, counterToInject, mockMyFoo);
#Test
public void shouldCallMethod() {
toTest.myMethod(true);
verify(toTest).otherMethod();
}
}
so that I am explicitly stating which constructor to call when I create my test object, and what arguments to pass to it.
There are some reasons not to rely on #InjectMocks to do this step for me, particularly if the class being tested is more complex and has more than one constructor. Mockito chooses the constructor that has the most arguments, but if there are several constructors with the same number of arguments, Mockito could choose any of the constructors; that is, the behaviour is undefined.
Once Mockito has chosen a constructor, it checks whether that constructor can in fact be used for constructor injection. Constructor injection will not be used if
one or more of the parameters of the chosen constructor is a primitive type,
the type of one or more of the parameters of the chosen constructor is a final class,
the type of one or more of the parameters of the chosen constructor is a private class,
the only constructor of the class is the default constructor.
If any one of these conditions holds, for the constructor that Mockito chose, then constructor injection won’t be used. In this case, the class must have a default constructor, otherwise Mockito will throw an exception.
The complexity of the criteria which Mockito uses when choosing whether to apply constructor injection implies that adding or removing a constructor, or changing the parameters of a constructor, can make Mockito switch from using constructor injection to using setter and field injection; or from using setter and field injection to using constructor injection. This can occur even if the constructor that is changed is not the one that will be used for constructor injection.
As a result, any test that uses constructor injection is automatically quite brittle; in the sense that changes that are not directly related to the test itself can cause the test to fail. Such failures can be difficult to troubleshoot.
The #InjectMocks annotation was designed for use with frameworks such as Spring that do dependency injection; and for tests of classes that use Spring, it can be invaluable. But if dependency injection is not part of your class, I would strongly recommend avoiding #InjectMocks on account of its brittleness. You really want your test code to be as easy to maintain and to troubleshoot as your production code is.

This is not recommended, but you can spy real object :)
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Spy;
import org.mockito.runners.MockitoJUnitRunner;
import static org.mockito.BDDMockito.verify;
#RunWith(MockitoJUnitRunner.class)
public class MyClassTest {
#Spy
private MyClass sut; // System Under Test
#Test
public void shouldCallMethod() {
// when
sut.myMethod(true);
// then
verify(sut).otherMethod();
}
}
Result:
Tests Passed: 1 passed in 0,203 s
After changing code: sut.myMethod(false);
Wanted but not invoked:
sut.otherMethod();
-> at my.custom.MyClassTest.shouldCallMethod(MyClassTest.java:23)
Source: Spying on real objects
Magic version with constructor injection
#Mock
private LexAnalyzer lexAnalyzer;
#Spy
#InjectMocks
private SyntaxAnalyzer sut; // System Under Test
#Test
public void shouldCallMethod() {
// when
sut.myMethod(true);
// then
verify(sut).otherMethod();
}
SyntaxAnalyzer.java
public class SyntaxAnalyzer {
private final LexAnalyzer lexAnalyzer;
public SyntaxAnalyzer(LexAnalyzer lexAnalyzer) {
this.lexAnalyzer = lexAnalyzer;
}
...
Tested, works ;)

I think you want to look at Mock objects. You can create a mock of MyClass, then set expectations that otherMethod() is called when you call myMethod and fails if it was not called.
Here is a pretty good overview of them for java - http://www.scalatest.org/user_guide/testing_with_mock_objects
One other major benefit of using Mocks, you can avoid side affects, like logging to NSLog or hitting a web server or printing) in your test.

Can I mock a super class method call?

Sometimes, you want to test a class method and you want to do an expectation on a call of a super class method. I did not found a way to do this expectation in java using easymock or jmock (and I think it is not possible).
There is a (relative) clean solution, to create a delegate with the super class method logic and then set expectations on it, but I don't know why and when use that solution ¿any ideas/examples?
Thanks

Well, you can if you want to. I don't know if you are familiar with JMockit, go check it out. The current version is 0.999.17 In the mean time, let's take a look at it...
Assume the following class hierarchy:
public class Bar {
public void bar() {
System.out.println("Bar#bar()");
}
}
public class Foo extends Bar {
public void bar() {
super.bar();
System.out.println("Foo#bar()");
}
}
Then, using JMockit in your FooTest.java you can validate that you're actually making a call to Bar from Foo.
#MockClass(realClass = Bar.class)
public static class MockBar {
private boolean barCalled = false;
#Mock
public void bar() {
this.barCalled = true;
System.out.println("mocked bar");
}
}
#Test
public void barShouldCallSuperBar() {
MockBar mockBar = new MockBar();
Mockit.setUpMock(Bar.class, mockBar);
Foo foo = new Foo();
foo.bar();
Assert.assertTrue(mockBar.barCalled);
Mockit.tearDownMocks();
}

Expanding on #Cem Catikkas answer, using JMockit 1.22:
#Test
public void barShouldCallSuperBar() {
new MockUp<Bar>() {
#Mock
public void bar() {
barCalled = true;
System.out.println("mocked bar");
}
};
Foo foo = new Foo();
foo.bar();
Assert.assertTrue(mockBar.barCalled);
}
No need for the static class annotated with #MockClass, it is replaced by the MockUp class.

I don't think I'd mock out a super call - it feels to me like the behaviour there is part of the behaviour of the class itself, rather than the behaviour of a dependency. Mocking always feels like it should be to do with dependencies more than anything else.
Do you have a good example of the kind of call you want to mock out? If you want to mock out a call like this, would it be worth considering composition instead of inheritance?

There are several tests that do just that (ie specify an expected invocation on a super-class method) using the JMockit Expectations API, in the Animated Transitions sample test suite. For example, the FadeInTest test case.

No, there is no way of mocking super class methods with jMock.
However there is a quick-and-dirty solution to your problem. Suppose you have class A and class B extends A. You want to mock method A.a() on B. You can introduce class C extends B in your test code and override the method C.a() (just call super, or return null, id does not matter). After that mock C and use the mock everywhere, where you'd use B.

intercepting a super call is much too fine-grained. Don't overdo the isolation.