How to use shouldVerifyCorrectlyWithAnyVarargs method of org.mockitousage.bugs.varargs.VarargsAndAnyObjectPicksUpExtraInvocationsTest class

Following Francisco González's answer, this is what I had to do :

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-junit4</artifactId>
    <version>1.5.5</version>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>org.javassist</groupId>
                <artifactId>javassist</artifactId>
        </exclusion>
    </exclusions>      
</dependency>
<dependency>
    <groupId>org.javassist</groupId>
    <artifactId>javassist</artifactId>
    <version>3.20.0-GA</version>
    <scope>test</scope>
</dependency>

Let's first separate interfaces from classes.

Interfaces are great for mocking (thus allowing for testing your app without the need for the sluggish GWTTestCase):

• IsWidget: when all you need is a handle on a widget, without depending on the Widget class. This is typically used with MVP as a way to represent the view.
• AcceptsOneWidget: when you need a placeholder for a single widget (in the form of an IsWidget). This is typically used with Activities, to insert the view (IsWidget) into the given slot (AcceptsOneWidget).

The classes you list all extend Widget, so they rely on JSNI and (most of the time) need to run in a GWT environment (for unit tests, that means a GWTTestCase):

• Widget: the base of all widgets. Implements IsWidget returning itself from asWidget().
• Composite: a base class when you need to create a widget built from other widgets while hiding their implementation. While you could extend an existing widget, it's generally better to hide it inside a Composite so you only expose the API you need/want to expose. Composite is about "composition rather than inheritance" and encapsulation. Examples of composites in standard widgets include TabPanel (built from a TabBar and DeckPanel), DateBox (built from a TextBox and DatePicker in a PopupPanel), ValueListBox that wraps a ListBox or ValuePicker that wraps a CellList. In many cases, given that panels accept IsWidget children, you could simply implement IsWidget rather extend Composite, but it's sometimes useful to have a true Widget.
• SimplePanel a panel that implements AcceptsOneWidget, useful as a slot when using activities (but you could also easily implement AcceptsOneWidget to insert into any kind of panel)

That being said, Google recently open-sourced GWT-Mockito that plugs Mockito into GWT.create() and uses classloader magic to rewrite JSNI methods and remove final modifiers so you can directly use widgets in tests without the need for GWTTestCase or MVP.

So, all in all, it depends how you approach your code, how you architecture your app. If you use MVP, stick to depending on interfaces only (IsWidget, AcceptsOneWidget) in your presenter so you can easily mock your view in your tests.
Otherwise, or if you want a "simplified MVP" where the view is a UiBinder template, try GWT-Mockito for your tests and directly use widgets.
Of course, you can mix both approaches in the same application. And in any case, build your own widgets as Widgets for low-level things (rarely needed), and Composites or IsWidgets for everything else, rather than extending existing widgets.

You can call ArgumentCaptor.getAllValues() instead of getValue(). This will return all captured values:

Returns all captured values. Use it when capturing varargs or when the verified method was called multiple times.

In this case, it will return a List<String> containing 1 and 2.

The getValue() method only returns the last captured value:

Returns the captured value of the argument.

If the method was called multiple times then it returns the latest captured value

In your code, you can replace atLeastOnce() with the more precise times(2) since the mock was called 2 times. You don't need to have two distinct calls to verify to capture the arguments: Mockito will be able to capture all arguments passed to the mock with just one call.

TestMock mock = Mockito.mock(TestMock.class);
mock.doIt("1");
mock.doIt("2");

ArgumentCaptor<String> argument = ArgumentCaptor.forClass(String.class);
verify(mock, times(2)).doIt(argument.capture()); // verify that it was call 2 times and capture the values given

System.out.println(argument.getAllValues());

You should instantiante testRef as follows:

Test testRef = new Test(taskJob) {

    public void updateAndReschedule(Long id, String message) {
        //do nothing
    }

};

No need for the spy.

Also, a slightly more terse way to get around this is to use the do syntax instead of when.

doReturn(User.class).when(methodParameter).getParameterType();

Moving away from the now unmaintained (as of this writing) Spingockito-annotations and to Mockito, we have a way of doing this very simply:

@RunWith(MockitoJUnitRunner.class)
@ContextConfiguration
public class MyTestClass {

    @Mock MockInterface mockObj;

    // test code
}

If you're using a real object, but would like to mock a dependency within it, for instance testing a service layer with DAO:

@RunWith(MockitoJUnitRunner.class)
@ContextConfiguration
public class MyTestClass {

    @InjectMocks RealService;

    @Mock MockDAO mockDAO;

    // test code
}

Finally, this can also be applied to Spring-boot, but using annotation initialization within setUp() until multiple class runners are supported:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = MyMainSpringBootClass.class)
public class MyTestClass {

    @InjectMocks RealService;

    @Mock MockDAO mockDAO;

    @Before
    public final void setUp() throws Exception{
        MockitoAnnotations.initMocks(this);
    }

    // test code
}

You are reusing your context, in order to have tests independent from one another you probably need to refresh your context after each test to reset everything.

I will suppose you are using Junit 4.5+. It would be similar with other test frameworks.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"mycontext.xml"})
@DirtiesContext(classMode = ClassMode.AFTER_EACH_TEST_METHOD)
public class MyTestClass {
...
    // my tests    
...
}

You can put the @DirtiesContext at the method level if the methods that need "fixing" are few, but if you are using Spring your best option is to do it after every test.

Anyway, I don't think you should be using mocks/spies in integration tests:

• In unit tests, use mocks (if you want) and inject manually. Here you want to verify the behaviour of your tested bean as a unit, so you isolate it from the rest by using mocks. This also has the advantage that JUnit isolates your tests by using a different instance of the test class for each test, so unless you use static or other test-unfriendly practices everything will just work.

• In integration tests, use real beans and let Spring inject. Here the goal is to verify that beans interact well with one another / with the environment (database, network, ...) You do not want to isolate beans here, so you should not use mocks.

See Spring documentation about testing for more detailed explanations.

This is a bug that occurs when you use JUnit 4.12 and PowerMock < 1.6.1. The problem is solved in PowerMock 1.6.1. Please update your dependencies accordingly

testCompile 'junit:junit:4.12',
            'org.powermock:powermock-core:1.6.1',
            'org.powermock:powermock-module-junit4:1.6.1',
            'org.powermock:powermock-api-mockito:1.6.1'

If you cannot upgrade PowerMock then you can use JUnit 4.11.

testCompile 'junit:junit:4.11',
            'org.powermock:powermock-core:1.5.6',
            'org.powermock:powermock-module-junit4:1.5.6',
            'org.powermock:powermock-api-mockito:1.5.6'

Could you please add further lines of the stacktrace, which uncover more details about the problem.

I would try any(byte[].class)