How to use shouldMatchVarArgs_twoArgsThreeAnyMatcher method of org.mockitousage.matchers.VarargsTest class

Some open source modules include optional java doc jars. To remove them add a configuration mapping to each of your dependencies:

   <dependency org="junit" name="junit" rev="4.8.2" conf="default"/>

The default configuration in ivy is equivalent to the the compile scope in a maven module. This is how the optional libraries can be automatically omitted. (Check their POMs).

A better approach is to declare your own configurations and the default mapping as follows:

<configurations defaultconfmapping="compile->default">
   <conf name="compile" description="Required to compile code"/>
   <conf name="test" description="Additional test dependencies" extends="compile" />
</configurations>

Then in your ivy file you only need to declare the non-standard configurations:

<dependencies>
    <dependency org="org.hamcrest" name="hamcrest-library" rev="1.3.RC2" conf="test->default"/>
    <dependency org="junit" name="junit" rev="4.8.2" conf="test->default"/>
    <dependency org="org.mockito" name="mockito-core" rev="1.8.5" conf="test->default"/>
    <dependency org="javax.persistence" name="persistence-api" rev="1.0"/>
</dependencies>

In this case we only want the 3 test libraries to appear on the test configuration.

Still confused? The magic of ivy configurations is when you use them to manage your build's class path

  <target name='dependencies' description='Resolve project dependencies and set classpaths'>
    <ivy:resolve/>

    <ivy:cachepath pathid="compile.path"  conf="compile"/>
    <ivy:cachepath pathid="test.path"     conf="test"/>
  </target>

This is what Maven is doing when you declare a scope tag on a dependency, for example:

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.8.2</version>
    <scope>test</scope>
</dependency>

The scopes in Maven are fixed. In ivy you can have as many as you need.

older question, but worth answering anyway... In eclipse, open the pom.xml file from the project. When it opens, select the Dependency Hierarchy tab at the bottom. In here you will see what is loading and where it is being called from. In the search filter, type the name (or part of the name) of the dependency that you think is in conflict, for example you could put in "slf4j" and see all the dependencies that depend on slf4j for logging. If you right click on any dependency, you can choose to exclude it in the pom file. When you save the pom.xml file, you will see the Dependency Hierarchy change. You can test your application again and see if you solved your problem, or excluded the wrong version, etc.

The only caveat to this is that if you want to put the dependency that you excluded back in, you need to switch to the "pom.xml" tab at the bottom and find the code that looks like this and delete it:

<exclusions>
  <exclusion>
    <artifactId>[artifactId of what you removed]</artifactId>
    <groupId>[groupId of what you removed]</groupId>
  </exclusion>
</exclusions>

Changes take place when you save the pom.xml file.

You need create real A class because you want to test it but you need to mock other classes used in A class. Also, you can find mockito documentation says that don't mock everything.

class ATest {
        @Mock
        private B b;
        private A a;
        @Before
        public void init() {
            MockitoAnnotations.initMocks(this);
            a = new A(b);
        }
        @Test
        public String someMethodTest() {
            String result = "result";
            Mockito.when(b.execute()).thenReturn(result);
            String response = a.someMethod();
            Mockito.verify(b,  Mockito.atLeastOnce()).execute();
            assertEquals(response, result);
        }
    }

I had the following problem: I had a method that was returning a Page<...> ,but I can use doNothing() only on void method ,so the fix is easy:

    @Override
    public Page<ThreadServiceModel> findAll(Pageable pageable) {
        return this.findAll(ThreadServiceModel.class, pageable);
    }

And here we go:

        //Will fail and the actualy findAll will be invoked:
        when(this.threadServices.findAll(ThreadServiceModel.class,pageable)).thenReturn(null);

        //Will fail ,cuz you cannot call doNothing() on something that returns values

        doNothing().when(this.threadServices).findAll(ThreadServiceModel.class,pageable);

        //This is the solution ,and when you use doReturn() the actual method will be NOT invoked,
        //+In my case i dont need value , but if i want I cant use...
        doReturn(null).when(this.threadServices).findAll(ThreadServiceModel.class,pageable);

So the solution is simple ,use the last method on the code that I have showed you :)

Nutshell: Can't always use when to stub spies; use doReturn.

Assuming static imports of spy and doReturn (both PowerMockito):

@RunWith(PowerMockRunner.class)
@PrepareForTest(B.class)
public class BTest {
    @Test public void testClass() throws Exception {
        B b = spy(new B());
        doReturn(42).when(b, "m");
        b.asd();
    }
}

You could also @PrepareForTest(A.class) and set up the doReturn on when(a, "m"). Which makes more sense depends on the actual test.

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)

Using void reset(T... mocks) will reset all stubbings on the mocks. If you just need to reset the invocation counts for subsequent verifications, use void clearInvocations(T... mocks).

@Test
public void persistGenericModelsAsync() throws JsonProcessingException {

    //stubbed - but never used
    when(restTemplate.exchange(Mockito.anyString(), Mockito.eq(HttpMethod.POST), Mockito.any(HttpEntity.class), Mockito.eq(JsonNode.class))).thenReturn(response);

    //stubbed - but never used
    when(response.getHeaders()).thenReturn(headers);
    List<String> cookiesTest = Arrays.asList("TxCartIdtest", "test");
    //stubbed - but never used
    when(headers.get(ValueConstant.SET_COOKIE)).thenReturn(cookiesTest);
    //stubbed - but never used
    when(response.getBody()).thenReturn(jsonNode);
}

Its clear that, none of the stubs you created with when() is getting used any where. For Eg. , the first stub where you return a response object - you have never used a call to restTemplate.exchange() any where in test execution of this method.

When you use the strict stubbing mode, you need to make sure - you use any stub that you create. See more here

You can use Mockitos Answer.

doAnswer(new Answer() {
     @Override
     public Object answer(InvocationOnMock invocation) {
         Object[] args = invocation.getArguments();
         ByteArrayOutputStream baos = (ByteArrayOutputStream)args[0];
         //fill baos with data
         return null;
     }
 }).when(client).retrieveFile(baos);

However, if you have possibility to refactor the tested code, better is to make client return the OutputStream or some data that can be put to this Output stream. This is would be much better design.