How to use getCacheDirFromInstrumentationRegistry method of org.mockito.android.internal.creation.AndroidTempFileLocator class

The problem is, you cannot mix argument matchers and real arguments in a mocked call. So, rather do this:

when(serviceValidatorStub.validate(
    any(),
    isA(UserCommentRequestValidator.class),
    eq(UserCommentResponse.class),
    eq(UserCommentError.class))
).thenReturn(new UserCommentResponse());

Notice the use of the eq() argument matcher for matching equality.

see: https://static.javadoc.io/org.mockito/mockito-core/1.10.19/org/mockito/Matchers.html#eq(T)

Also, you could use the same() argument matcher for Class<?> types - this matches same identity, like the == Java operator.

Static methods aren't related to any object - your helper.fetchUsernameFromInternet(...) is the same (but a bit confusing) as HelperUtils.fetchUsernameFromInternet(...) - you should even get a compiler warning due to this helper.fetchUsernameFromInternet.

What's more, instead of Mockito.mock to mock static methods you have to use: @RunWith(...), @PrepareForTest(...) and then PowerMockito.mockStatic(...) - complete example is here: PowerMockito mock single static method and return object

In other words - mocking static methods (and also constructors) is a bit tricky. Better solution is:

• if you can change HelperUtils, make that method non-static and now you can mock HelperUtils with the usual Mockito.mock

• if you can't change HelperUtils, create a wrapper class which delegates to the original HelperUtils, but doesn't have static methods, and then also use usual Mockito.mock (this idea is sometimes called "don't mock types you don't own")

Why it doesn't work

Well your problem here is that TransactionTemplate in your test is a mock. As such it has the same interface as TransactionTemplate but it does not know how to behave. You are in charge of its implementation - that's the whole point of mocks. You are explicitly calling template.execute() in your code and that is why your first verify passes. But that execute() isn't the one from Spring (or more precisely template in your test isn't an instance of Spring's TransactionTemplate, it's only a mock of it) - it's, well lets say it's "empty" as it is invoked on a mock and you did not tell the mock how invoking execute() on it should behave.

How I would fix it

In cases like this I would really discourage you from such unit tests because you are testing implementation here. What you should test, at least according to me, is the functionality meaning given certain conditions, when something happens then some result should occur. This would require changing this to an integration test (using lets say DBUnit or anything else) and asserting if you actually deleted what you were supposed to delete. I mean what do you really care about - knowing that some methods got invoked or that something you hoped for actually happened?

How you can, but IMHO shouldn't, fix it.

But if you really want to test that anonymous piece of code then I would simply extract it (the whole anonymous class) to a separate class and write a unit test just for that new class and more precisely for it's doInTransaction() method. In that case you would create it using new, setting a mock DataWarehouseMessageDao in it and simply do your verify().

Try View -> Tool Windows -> Maven projects, then click the blue icon in the top left of the tool window (Reimport all Maven projects). You should be able to find the dependencies in the project view, under external libraries.

If this does not work, there is probably something wrong with your maven config (pom.xml). Try mvn clean install from the command line see if it gives any errors.

Mockito itself doesn't seem to be able to mock native methods according to this Google Group thread. However you do have two options:

1. Wrap the TableElement class in an interface and mock that interface to properly test that your SUT calls the wrapped insertRow(...) method. The drawback is the extra interface that you need to add (when GWT project should've done this in their own API) and the overhead to use it. The code for the interface and the concrete implementation would look like this:

   // the mockable interface
   public interface ITableElementWrapper {
       public void insertRow(int index);
   }
   
   // the concrete implementation that you'll be using
   public class TableElementWrapper implements ITableElementWrapper {
       TableElement wrapped;
   
       public TableElementWrapper(TableElement te) {
           this.wrapped = te;
       }
   
       public void insertRow(int index) {
           wrapped.insertRow(index);
       }
   }
   
   // the factory that your SUT should be injected with and be 
   // using to wrap the table element with
   public interface IGwtWrapperFactory {
       public ITableElementWrapper wrap(TableElement te);
   }
   
   public class GwtWrapperFactory implements IGwtWrapperFactory {
       public ITableElementWrapper wrap(TableElement te) {
           return new TableElementWrapper(te);
       }
   }
   

2. Use Powermock and it's Mockito API extension called PowerMockito to mock the native method. The drawback is that you have another dependency to load into your test project (I'm aware this may be a problem with some organizations where a 3rd party library has to be audited first in order to be used).

Personally I'd go with option 2, as GWT project is not likely to wrap their own classes in interfaces (and it is more likely they have more native methods that needs to be mocked) and doing it for yourself to only wrap a native method call is just waste of your time.

I recommend you to keep tests simple. You can take profit of DI benefits. For further details please visit Spring documentation:

One of the major advantages of dependency injection is that it should make your code easier to unit test. You can simply instantiate objects using the new operator without even involving Spring. You can also use mock objects instead of real dependencies.

Your test class should look like this.

public class AddressTest {

    @Mock
    private UserDAO userDAO;

    @Mock
    private AddressDAO addressDAO;

    @InjectMocks
    private AddressService addressServie;

    @BeforeMethod
    public void initMock() {
        addressServie = new AddressServiceImpl();
        MockitoAnnotations.initMocks(this);
    }

    @Test(dataProvider = "getUser", dataProviderClass = UserDP.class)
    public void shouldThrowExceptionAddressNotFound(int userId, User user) {
        when(userDAO.findOne(userId)).thenReturn(user);
        try {
            addressServie.findAllAddress(userId);
        } catch (BadRequestException badRequestException) {
            assertEquals(badRequestException.getErrorCode(), 102);
        }
    }
}

You should also check for null address list in your implementation. The test fails because provider class provides the test with a user instance that does not have address list initialized.

@Override
public List<Address> findAllAddress(int userId) {
    User user = userDAO.findOne(userId);
    if (user == null) {
        throw new BadRequestException("Invalid user id", 101);
    }
    List<Address> addresses = user.getAddresses();
    if (addresses == null || addresses.isEmpty()) {
        throw new BadRequestException("Address Not found", 102);
    }
    return addresses;
}

I think you do need to cast it, but it shouldn't be too bad:

Foo<Bar> mockFoo = (Foo<Bar>) mock(Foo.class);
when(mockFoo.getValue()).thenReturn(new Bar());

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();
    }

how about you create an anonymous exception of type JsonProcessingException

when(mapper.writeValueAsString(any(Object.class))).thenThrow(new JsonProcessingException("Error"){});

The {} braces does the trick. This is much better since it is not confusing to the reader of the test code.