Mocking static method of the interface in Java - java

I got an interface with a static method in it. And I want to mock this method for unit tests.
Here's an example of such an interface:
public interface IClass {
static String create(String s) {
System.out.println("Method create is called");
return s;
}
}
I was trying to mock this method using PowerMockito:
#RunWith(PowerMockRunner.class)
#PrepareForTest(IClass.class)
public class IClassTest {
#Before
public void setUp() {
PowerMockito.mockStatic(IClass.class);
ClassImpl cl = mock(ClassImpl.class);
Mockito.when(IClass.create(any())).thenReturn(cl);
}
#Test
public void mockInterfaceClassTest() {
System.out.println(IClass.create("Test"));
}
}
Unfortunately, the mocking is not being done and even more, as soon as in my setUp() method I'm trying to setup mock: Mockito.when(IClass.create(any())).thenReturn(cl); actually, the method is being called (I got message in console "Method create is called"), which is undesired for sure.
Is there any possibility to mock static method inside interface?

Related

Is there any way to Mock the private method , which is there in other class

As per my knowledge, We can Mock the private method in same class by using PowerMockito.
With in the same class is working fine for me , but when i'm calling private method from the other class it's not working.
Below Example i've 2 classes , Service class and Helper classes
Helper class having private method.
#RunWith(PowerMockRunner.class)
#PrepareForTest({ Helper.class,Service.class })
#PowerMockIgnore("javax.management.*")
public class EPartnerBatchServiceTest {
private Helper helper;
#InjectMocks
private ServiceClass serviceClass;
#Before
public void setUp() throws Exception {
helper = PowerMockito.spy(new Helper());
ServiceClass = PowerMockito.spy(new serviceClass());
MockitoAnnotations.initMocks(this);
}
#Test
public void testUpdateIndividualUserStatus() throws Exception {
PowerMockito.doReturn("Test").when(helper, "privateMethod", anyString(), Matchers.anyObject());
String response = serviceClass.update(loggerId, activityLogDTO);
}
}
Sample Classes :
Class A{
value=new B().method1();
}
Class B{
public method1(){
value = method2();
}
private method2(){
return "Test";
}
}
You shouldn't be worrying with testing explicitly your private methods, since they are not accessible for the ones calling it, it's function should be tested somewhere in the flow of your public methods. But, if for some reason you need to test them explicitly, then maybe reflections and setting those methods as accessible for testing may resolve your problem.
You'll find great examples here: https://www.baeldung.com/java-method-reflection

How to use two different argument captors in one test method?

I have a problem using captors to test two separate calls of the same method, but with different argument type.
I provided a code sample of what I'm trying to do here - basically I want to verify if certain method was called twice but with different type arguments using two separate captors, and then call some assertions on captured objects.
public class Foo {
}
public class Bar {
}
public interface MyClient {
void doSomething(Object obj);
}
public class MyService {
private MyClient client;
void doSomething() {
client.doSomething(new Foo());
client.doSomething(new Bar());
}
}
#RunWith(MockitoJUnitRunner.class)
public class MyServiceTest {
#InjectMocks
private MyService testObj;
#Mock
private MyClient myClient;
#Captor
private ArgumentCaptor<Foo> fooCaptor;
#Captor
private ArgumentCaptor<Bar> barCaptor;
#Test
public void testSomething() {
testObj.doSomething();
verify(myClient).doSomething(fooCaptor.capture());
// ...do something with fooCaptor
verify(myClient).doSomething(barCaptor.capture());
// ...do something with barCaptor
}
}
I'd expect this test would pass as is, because captors specify argument types, so shouldn't this work same as ArgumentMatchers.any(Foo.class) etc?
Currently I'm getting TooManyActualInvocations - 2 instead of 1.
How do we handle such cases? I don't like the idea of using one captor and then cast the results.
Try to combine the captors with the isA matcher using the and operator from the AdditionalMatchers package.
import static org.mockito.AdditionalMatchers.and;
// ...
verify(myClient).doSomething(and(isA(Foo.class), fooCaptor));
verify(myClient).doSomething(and(isA(Bar.class), barCaptor));

Mockito Not Able to Mock function call present in target class's constructor

I am trying to test the following class using Mockito and JUnit :
public class A {
private SomeClass someObject;
private SomeImpClass someImpObject1;
private SomeImpClass2 someImpObject2;
public A(SomeImpClass someImpObject1, SomeImpClass2 someImpObject2){
someObject = makeNewObject(someImpObject1, someImpObject2);
}
public makeNewObject(SomeImpClass1 someImpObject1, SomeImpClass2 someImpObject2){
return new SomeObject(someImpObject1,someImpObject2);
}
public usingSomeObject(){
someObject.doSomething();
}
}
So, I wrote a Unit Test using Mockito and JUnit :
#RunWith(MockitoJUnitRunner.class)
public class ATest {
#Mock
SomeImpClass1 someImpObject1;
#Mock
SomeImpClass2 someImpObject2;
#Mock
SomeObject someObject;
#Spy
A a;
#Before
public void setUp() {
when(A.makeNewObject).thenReturn(someObject);
this.A = new A(this.someImpObject1, someImpObject2);
when(someObject.doSomething).thenReturn(something);
}
}
The Issue I am facing here is, although I have stubbed the function makeNewObject to return a Mocked object of SomeClass, the code flow is still going inside the fucntion (makeNewObject) and giving a null exception.
What Am I Doing Wrong ?
I have wasted a day behind this.
Not Very Fluent with Mockito.
You wont be able to achieve what you are aiming for with spying and stubbing.
This is because your aiming at stubbing a method used in a constructor.. but you cannot start stubbing once you created a concrete object and spy it.. can't be done..
I would suggest creating a private class inside the test class which extends your class under test, override the method invoked in the constructor and then use it in your tests:
#RunWith(MockitoJUnitRunner.class)
public class ATest {
#Mock
SomeObject someObjectMock;
A a;
#Before
public void setUp() {
this.a = new MyTest();
}
private class MyTest extends ATest{
#Override
public makeNewObject(SomeImpClass1 someImpObject1, SomeImpClass2 someImpObject2){
return someObjectMock;
}
}
Now you dont need to use spying and stubbing of it also as the overriden method is always returning what you expect in the test.

PowerMockito fails to mock final method intermittently

I am using TestNG 6.8.8, Mockito 1.9.5 and PowerMock 1.5.4. When I mock Child class and call stubbed final method, the test passes sometimes and fails sometimes with error MissingMethodInvocationException.
Is this a PowerMock bug?
public abstract class Parent implements Serializable {
protected abstract void validate();
public final Date getLastModified() {
return lastModified;
}
}
public class Child extends Parent {
#Override
protected void validate() {
// nothing for now.
}
}
import static org.powermock.api.mockito.PowerMockito.when;
#PrepareForTest({ Parent.class, Child.class })
public class ChildTest {
#Test
public final void testChildMethod() {
Child childObj = PowerMockito.mock(Child.class);
when(childObj.getLastModified()).thenReturn(new Date());
TestCodeThatResultsInCallToChild.getLastModified();
}
}
Error message:
when() requires an argument which has to be &apos;a method call on a mock&apos;.
For example:
when(mock.getArticles()).thenReturn(articles);
Also, this error might show up because:
1. you stub either of: final/private/equals()/hashCode() methods.
Those methods *cannot* be stubbed/verified.
2. inside when() you don&apos;t call method on mock but on some other object.
3. the parent of the mocked class is not public.
It is a limitation of the mock engine.
" type="org.mockito.exceptions.misusing.MissingMethodInvocationException

What order are the Junit #Before/#After called?

I have an Integration Test Suite. I have a IntegrationTestBase class for all my tests to extend. This base class has a #Before (public void setUp()) and #After (public void tearDown()) method to establish API and DB connections. What I've been doing is just overriding those two methods in each testcase and calling super.setUp() and super.tearDown(). However this can cause problems if someone forgets to call the super or puts them at the wrong place and an exception is thrown and they forget to call super in the finally or something.
What I want to do is make the setUp and tearDown methods on the base class final and then just add our own annotated #Before and #After methods. Doing some initial tests it appears to always call in this order:
Base #Before
Test #Before
Test
Test #After
Base #After
but I'm just a little concerned that the order isn't guaranteed and that it could cause problems. I looked around and haven't seen anything on the subject. Does anyone know if I can do that and not have any problems?
Code:
public class IntegrationTestBase {
#Before
public final void setUp() { *always called 1st?* }
#After
public final void tearDown() { *always called last?* }
}
public class MyTest extends IntegrationTestBase {
#Before
public final void before() { *always called 2nd?* }
#Test
public void test() { *always called 3rd?* }
#After
public final void after() { *always called 4th?* }
}
Yes, this behaviour is guaranteed:
#Before:
The #Before methods of superclasses will be run before those of the current class, unless they are overridden in the current class. No other ordering is defined.
#After:
The #After methods declared in superclasses will be run after those of the current class, unless they are overridden in the current class.
One potential gotcha that has bitten me before:
I like to have at most one #Before method in each test class, because order of running the #Before methods defined within a class is not guaranteed. Typically, I will call such a method setUpTest().
But, although #Before is documented as The #Before methods of superclasses will be run before those of the current class. No other ordering is defined., this only applies if each method marked with #Before has a unique name in the class hierarchy.
For example, I had the following:
public class AbstractFooTest {
#Before
public void setUpTest() {
...
}
}
public void FooTest extends AbstractFooTest {
#Before
public void setUpTest() {
...
}
}
I expected AbstractFooTest.setUpTest() to run before FooTest.setUpTest(), but only FooTest.setupTest() was executed. AbstractFooTest.setUpTest() was not called at all.
The code must be modified as follows to work:
public void FooTest extends AbstractFooTest {
#Before
public void setUpTest() {
super.setUpTest();
...
}
}
I think based on the documentation of the #Before and #After the right conclusion is to give the methods unique names. I use the following pattern in my tests:
public abstract class AbstractBaseTest {
#Before
public final void baseSetUp() { // or any other meaningful name
System.out.println("AbstractBaseTest.setUp");
}
#After
public final void baseTearDown() { // or any other meaningful name
System.out.println("AbstractBaseTest.tearDown");
}
}
and
public class Test extends AbstractBaseTest {
#Before
public void setUp() {
System.out.println("Test.setUp");
}
#After
public void tearDown() {
System.out.println("Test.tearDown");
}
#Test
public void test1() throws Exception {
System.out.println("test1");
}
#Test
public void test2() throws Exception {
System.out.println("test2");
}
}
give as a result
AbstractBaseTest.setUp
Test.setUp
test1
Test.tearDown
AbstractBaseTest.tearDown
AbstractBaseTest.setUp
Test.setUp
test2
Test.tearDown
AbstractBaseTest.tearDown
Advantage of this approach: Users of the AbstractBaseTest class cannot override the setUp/tearDown methods by accident. If they want to, they need to know the exact name and can do it.
(Minor) disadvantage of this approach: Users cannot see that there are things happening before or after their setUp/tearDown. They need to know that these things are provided by the abstract class. But I assume that's the reason why they use the abstract class
If you turn things around, you can declare your base class abstract, and have descendants declare setUp and tearDown methods (without annotations) that are called in the base class' annotated setUp and tearDown methods.
You can use #BeforeClass annotation to assure that setup() is always called first. Similarly, you can use #AfterClass annotation to assure that tearDown() is always called last.
This is usually not recommended, but it is supported.
It's not exactly what you want - but it'll essentially keep your DB connection open the entire time your tests are running, and then close it once and for all at the end.
This isn't an answer to the tagline question, but it is an answer to the problems mentioned in the body of the question. Instead of using #Before or #After, look into using #org.junit.Rule because it gives you more flexibility. ExternalResource (as of 4.7) is the rule you will be most interested in if you are managing connections. Also, If you want guaranteed execution order of your rules use a RuleChain (as of 4.10). I believe all of these were available when this question was asked. Code example below is copied from ExternalResource's javadocs.
public static class UsesExternalResource {
Server myServer= new Server();
#Rule
public ExternalResource resource= new ExternalResource() {
#Override
protected void before() throws Throwable {
myServer.connect();
};
#Override
protected void after() {
myServer.disconnect();
};
};
#Test
public void testFoo() {
new Client().run(myServer);
}
}

Categories