How to use varargLength method of org.mockito.internal.invocation.MatcherApplicationStrategy class

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.

Just do it the usual way and then insert it using SecurityContextHolder.setContext() in your test class, for example:

Controller:

Authentication a = SecurityContextHolder.getContext().getAuthentication();

Test:

Authentication authentication = Mockito.mock(Authentication.class);
// Mockito.whens() for your authorization object
SecurityContext securityContext = Mockito.mock(SecurityContext.class);
Mockito.when(securityContext.getAuthentication()).thenReturn(authentication);
SecurityContextHolder.setContext(securityContext);

Mockito.doAnswer() will allow you to mock void methods and manipulate the parameters passed to it via your own closure/class implementing Answer (provided your parameters are mutable, obviously).

So given your code:

doAnswer(new Answer() {
    public Object answer(InvocationOnMock invocation) {
        Object[] args = invocation.getArguments();
        args[0] // that's the argument I want to modify
        return null;
    }})
 .when(parameterProvider).provideParameter(anyMap());

args[0] would be a Map (inspect via a debugger) and assuming it's mutable, you should be able to populate/change it within your anonymous class e.g.

((Map)args[0]).put(x, y);

PropertyDescriptor#getPropertyType() returns an object of Class<?>, where the ? means "this is a type, but I don't know what it is". Let's call this type "X". So when(mockDescriptor.getPropertyType()) creates an OngoingStubbing<Class<X>>, whose method thenReturn(Class<X>) can only accept objects of Class<X>. But the compiler doesn't know what type this "X" is, so it will complain about you passing in a Class of any type. I think this is the same reason the compiler complains about calling add(...) on a Collection<?>.

When you explicitly specify Class<?> for the type on the when method, you're not saying that mockDescriptor.getPropertyType() returns a Class<?>, you're saying that when returns an OngoingStubbing<Class<?>>. Then, the compiler checks to make sure whatever you're passing into when is of a type that matches Class<?>; since getPropertyType() returns the "Class<X>" I mentioned earlier, it of course matches the Class<?> you specified.

So basically

// the inferred type is Class<"some type">
Mockito.when(mockDescriptor.getPropertyType())

// the specified type is Class<"any type">
Mockito.<Class<?>>when(mockDescriptor.getPropertyType())

In my IDE, the error message for your original code is

The method thenReturn(Class<capture#1-of ?>) in the type OngoingStubbing<Class<capture#1-of ?>> is not applicable for the arguments (Class<String>)

That capture#1-of ? is the "X" I described above.

If you want to do a pure unit test then for the line

service.getJdbcTemplate().query("....");

You will need to mock the Service, then the service.getJdbcTemplate() method to return a mock JdbcTemplate object, then mock the query method of mocked JdbcTemplate to return the List you need. Something like this:

@Mock
Service service;

@Mock
JdbcTemplate jdbcTemplate;


@Test
public void testGetUserNames() {

    List<String> userNames = new ArrayList<String>();
    userNames.add("bob");

    when(service.getJdbcTemplate()).thenReturn(jdbcTemplate);
    when(jdbcTemplate.query(anyString(), anyObject()).thenReturn(userNames);

    String retVal = Class.getUserNames("test");
    assertEquals("bob", retVal);
}

The above doesn't require any sort of Spring support. If you were doing an Integration Test where you actually wanted to test that data was being pulled from a DB properly, then you would probably want to use the Spring Test Runner.

I think this should work:

    @PrepareForTest({UtilDatabaseSoldeAutoCdeCommon.class})
    public class SomeTest {
        @Mock
        UtilDatabaseSoldeAutoCdeCommon fakeSingletonInstance;   

        @Test
        public void test() {
             Whitebox.setInternalState(UtilDatabaseSoldeAutoCdeCommon.class, "instance", fakeSingletonInstance);
             // Write here your test
        }
    }

From the link you posted;

Default answer of every Mockito mock.

• Returns appropriate primitive for primitive-returning methods
• Returns consistent values for primitive wrapper classes (e.g. int-returning method retuns 0 and Integer-returning method returns 0, too)
• Returns empty collection for collection-returning methods (works for most commonly used collection types)
• Returns description of mock for toString() method
• Returns null for everything else

From the FAQ:

What values do mocks return by default?

In order to be transparent and unobtrusive all Mockito mocks by default return 'nice' values. For example: zeros, falseys, empty collections or nulls.

It was probably done to stay consistent with any other methods which return null for any other non-collection, non-primitive Wrapper objects.

You can always implement your own Answer to pass to mock which returns empty strings for String returning methods.

I got the answer we can do it in the following way

when(nodeIterator.hasNext()).thenReturn(true).thenReturn(false);

this is known as method stubbing. Similarly if you want to call it twice and then you want to return false, then do as follows

when(nodeIterator.hasNext()).thenReturn(true).thenReturn(true).thenReturn(false);

If you are mocking the behavior (with something like doNothing()) there should really be no need to call to verify*(). That said, here's my stab at re-writing your test method:

@PrepareForTest({InternalUtils.class})
@RunWith(PowerMockRunner.class)
public class InternalServiceTest { //Note the renaming of the test class.
   public void testProcessOrder() {
        //Variables
        InternalService is = new InternalService();
        Order order = mock(Order.class);

        //Mock Behavior
        when(order.isSuccessful()).thenReturn(true);
        mockStatic(Internalutils.class);
        doNothing().when(InternalUtils.class); //This is the preferred way
                                               //to mock static void methods.
        InternalUtils.sendEmail(anyString(), anyString(), anyString(), anyString());

        //Execute
        is.processOrder(order);            

        //Verify
        verifyStatic(InternalUtils.class); //Similar to how you mock static methods
                                           //this is how you verify them.
        InternalUtils.sendEmail(anyString(), anyString(), anyString(), anyString());
   }
}

I grouped into four sections to better highlight what is going on:

1. Variables

I choose to declare any instance variables / method arguments / mock collaborators here. If it is something used in multiple tests, consider making it an instance variable of the test class.

2. Mock Behavior

This is where you define the behavior of all of your mocks. You're setting up return values and expectations here, prior to executing the code under test. Generally speaking, if you set the mock behavior here you wouldn't need to verify the behavior later.

3. Execute

Nothing fancy here; this just kicks off the code being tested. I like to give it its own section to call attention to it.

4. Verify

This is when you call any method starting with verify or assert. After the test is over, you check that the things you wanted to have happen actually did happen. That is the biggest mistake I see with your test method; you attempted to verify the method call before it was ever given a chance to run. Second to that is you never specified which static method you wanted to verify.

Additional Notes

This is mostly personal preference on my part. There is a certain order you need to do things in but within each grouping there is a little wiggle room. This helps me quickly separate out what is happening where.

I also highly recommend going through the examples at the following sites as they are very robust and can help with the majority of the cases you'll need:

• https://github.com/powermock/powermock/wiki/Mockito (PowerMock Overview / Examples)
• (Mockito Overview / Examples)