How to use unused_and_lenient_stubbings method of org.mockitousage.internal.junit.UnusedStubbingsFinderTest class

I've just fixed same issue, and my workaround was this:

create a dummy Application and set theme inside onCreate():

public class TestApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        setTheme(R.style.AppTheme); //or just R.style.Theme_AppCompat
    }
}

then inside the test you specify the application class in config:

@RunWith(RobolectricTestRunner.class)
@Config(application = TestApplication.class)
public class YourActivityTest {
    //tests
}

Usually when you are unit testing, you shouldn't initialize Spring context. So remove Autowiring.

Usually when you do integration testing, you should use real dependencies. So remove mocking.

You are mixing integration and unit test here.

What you are asking is not possible because your legacy code relies on a static method getInstance() and Mockito does not allow to mock static methods, so the following line won't work

when(FormatterService.getInstance()).thenReturn(formatter);

There are 2 ways around this problem:

1. Use a different mocking tool, such as PowerMock, that allows to mock static methods.

2. Refactor your code, so that you don't rely on the static method. The least invasive way I can think of to achieve this is by adding a constructor to DriverSnapshotHandler that injects a FormatterService dependency. This constructor will be only used in tests and you production code will continue to use the real singleton instance.

   public static class DriverSnapshotHandler {
   
       private final FormatterService formatter;
   
       //used in production code
       public DriverSnapshotHandler() {
           this(FormatterService.getInstance());
       }
   
       //used for tests
       DriverSnapshotHandler(FormatterService formatter) {
           this.formatter = formatter;
       }
   
       public String getImageURL() {
           return formatter.formatTachoIcon();
       }
   }
   

Then, your test should look like this :

FormatterService formatter = mock(FormatterService.class);
when(formatter.formatTachoIcon()).thenReturn("MockedURL");
DriverSnapshotHandler handler = new DriverSnapshotHandler(formatter);
handler.getImageURL();
verify(formatter, atLeastOnce()).formatTachoIcon();

Mocking the iterator works for me. See below code sample:

import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

import java.util.Collection;
import java.util.Iterator;

import org.junit.Before;
import org.junit.Test;

public class TestMockedIterator {

    private Collection<String> fruits;
    private Iterator<String> fruitIterator;

    @SuppressWarnings("unchecked")
    @Before
    public void setUp() {
        fruitIterator = mock(Iterator.class);
        when(fruitIterator.hasNext()).thenReturn(true, true, true, false);
            when(fruitIterator.next()).thenReturn("Apple")
            .thenReturn("Banana").thenReturn("Pear");

        fruits = mock(Collection.class);
        when(fruits.iterator()).thenReturn(fruitIterator);
    }

    @Test
    public void test() {
        int iterations = 0;
        for (String fruit : fruits) {
            iterations++;
        }
        assertEquals(3, iterations);
    }
}

You may have some trouble with any or argThat for primitive-type arguments to when and verify. Those Object-centric methods do their work with side-effects correctly, but they tend to return null for a dummy return value, which doesn't work for Java unwrapping primitives via auto-boxing.

Luckily, the org.mockito.ArgumentMatchers class has a full complement of primitive-centric methods (of which I've listed the int methods here):

static int anyInt()
static int eq(int value)
static int intThat(org.hamcrest.ArgumentMatcher<java.lang.Integer> matcher)

See all of them at the documentation for the ArgumentMatchers class.

A good technique for getting rid of static calls on 3rd party API is hiding the static call behind an interface.

Let's say you make this interface :

interface IPDOFacade {

    IPDO getContextPDO();
}

and have a default implementation that simply calls the static method on the 3rd party API :

class IPDOFacadeImpl implements IPDOFacade {

    @Override
    public IPDO getContextPDO() {
        return Util.getContextPDO();
    }
}

Then it is simply a matter of injecting a dependency on the interface into MyClass and using the interface, rather than the 3rd party API directly :

public class MyClass {

    private final IPDOFacade ipdoFacade;

    public MyClass(IPDOFacade ipdoFacade) {
        this.ipdoFacade = ipdoFacade;
    }

    private IPDO getIPDO() {
        return ipdoFacade.getContextPDO();
    }

    public String handleIn(Object input) throws Throwable
    {
        String result = "";
        IPDO pdo = getIPDO();

        someImportantBusinessLogic(pdo);

        return result;
    }
    
    ...

}

In your unit test, you can then easily mock your own interface, stub it any way you like and inject it into the unit under test.

This

• avoids the need to make private methods package private.
• makes your tests more readable by avoiding partial mocking.
• applies inversion of control.
• decouples your application from a specific 3rd party library.

Since Mockito 1.9.5+ and Java 8+

You can use a lambda expression, like:

when(myMock.myFunction(anyString())).thenAnswer(i -> i.getArguments()[0]);

Where i is an instance of InvocationOnMock.

For older versions

You can create an Answer in Mockito. Let's assume, we have an interface named MyInterface with a method myFunction.

public interface MyInterface {
    public String myFunction(String abc);
}

Here is the test method with a Mockito answer:

public void testMyFunction() throws Exception {
    MyInterface mock = mock(MyInterface.class);
    when(mock.myFunction(anyString())).thenAnswer(new Answer<String>() {
    @Override
    public String answer(InvocationOnMock invocation) throws Throwable {
        Object[] args = invocation.getArguments();
        return (String) args[0];
    }
    });

    assertEquals("someString",mock.myFunction("someString"));
    assertEquals("anotherString",mock.myFunction("anotherString"));
}

The MockitoExtension class implements the BeforeEachCallback but not the BeforeAllCallback from JUnit-Jupiter-API. It does therefore not provide any additional behaviour for @BeforeAll annotated methods.

Source extract of MockitoExtension

public class MockitoExtension implements BeforeEachCallback, AfterEachCallback, ParameterResolver {

This is because you are not using the SpringJUnitClassRunner.

Mockito and your own classes are not taking the @Retryable annotation in account. So you rely on the implementation of Spring to do so. But your test does not activate Spring.

This is from the SpringJUnit4ClassRunner JavaDoc:

SpringJUnit4ClassRunner is a custom extension of JUnit's BlockJUnit4ClassRunner which provides functionality of the Spring TestContext Framework to standard JUnit tests by means of the TestContextManager and associated support classes and annotations. To use this class, simply annotate a JUnit 4 based test class with @RunWith(SpringJUnit4ClassRunner.class) or @RunWith(SpringRunner.class).

You should restructure your test class at least to something like:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes=MyConfig.class)
public class MyServiceTest {
    @Configuration
    @EnableRetry
    @Import(myService.class)
    public static class MyConfig {}
...

What am I doing there?

1. activate the Spring JUnit hook
2. specify the Spring context configuration class
3. define the spring configuration and import your service as a bean
4. enable the retryable annotation

Are there some other pitfalls?

• Yes, you are using Mockito to simulate an exception. If you want to test this behaviour with Spring like this, you should have a look at Springockito Annotations.
• But be aware of that: Springockito you will replace the spring bean completely which forces you to proxy the call of your retryable. You need a structure like: test -> retryableService -> exceptionThrowingBean. Then you can use Springockito or what ever you like e.g. ReflectionTestUtils to configure the exceptionThrowingBean with the behaviour you like.
• You should reference the interface type of your service in your test: MyServiceInterface
• And last but not least. There is a naming convention nearly all Java developers follow: class names have first letter of each internal word capitalized

Hope that helps.