How to use findTypeFromGeneric method of org.mockito.internal.stubbing.defaultanswers.RetrieveGenericsForDefaultAnswers class

In the spirit of providing a possible solution (and contrary to my comments above) you could try one of the following

Option 1

If TestClass implements an interface you could achieve a similar test using andDelegateTo() as described in this post that talks about Easymock not supporting spying

Option 2

Remove your need for spying by extending the TestClass specifically for your testing requirements. This is a common approach to dealing with legacy code bases where you cannot alter the code under test.

I will use Mockito in this example so that it is aligned with your question, however the concept will work the same with Easymock.

public class TestClassUsingMockito {
    /**
    We extend the original class under test so that we can override the creation of IndexData and
    thereby remove the responsibility of creating this object from the @Test method
    */
    private class ClassForTesting extends TestClass {

        private Lock lock;
        private IndexData indexData;

        public ClassForTesting(IndexData indexData, Lock lock) {
            this.indexData = indexData;
            this.lock = lock;
        }

        @Override
        protected IndexData getIndex(InputClass input) {
            return indexData;
        }
    }

    /**
    Look Ma' no more Spys!
    */
    @Test
    public void testAddUsesWriteLock() {        
        // Prepare
        final Lock lock = Mockito.mock(Lock.class);
        final IndexData indexData = Mockito.mock(IndexData.class);
        Mockito.doReturn(lock).when(indexData).getWriteLock();
        // ... now use your new subclass for testing
        final TestClass objectUnderTest = new ClassForTesting(indexData, lock);
        final InputClass input = Mockito.mock(InputClass.class);

        // Invoke method under test
        objectUnderTest.add(input);

        // Verify
        Mockito.verify(indexData).getWriteLock();
        Mockito.verify(indexData, Mockito.never()).getReadLock();
        Mockito.verify(lock).lock();
        Mockito.verify(lock).unlock(); 
    }
}

What is the analogon of Mockito.spy/doReturn in EasyMock?

So having removed the need for a Spy() in your tests the Mockito call

Mockito.doReturn(lock).when(indexData).getWriteLock();

Can be written in EasyMock as

expect(indexData.getWriteLock()).andStubReturn(lock);

EasyMock example of the same Mockito test above

public class TestClassUsingEasymock extends EasyMockSupport {

    private class ClassForTesting extends TestClass {

        private Lock lock;
        private IndexData indexData;

        public ClassForTesting(IndexData indexData, Lock lock) {
            this.indexData = indexData;
            this.lock = lock;
        }

        @Override
        protected IndexData getIndex(InputClass input) {
            return indexData;
        }
    }


    @Test
    public void testAddUsesWriteLock() {
        // Prepare
        final Lock lock = createNiceMock(Lock.class);       
        final IndexData indexData = createNiceMock(IndexData.class);
        EasyMock.expect(indexData.getWriteLock()).andStubReturn(lock);

        // ... now use your new subclass for testing
        final TestClass objectUnderTest = new ClassForTesting(indexData, lock);
        final InputClass input = createNiceMock(InputClass.class);

        lock.lock();
        EasyMock.expectLastCall();

        lock.unlock();
        EasyMock.expectLastCall();

        replayAll();

        // Invoke method under test
        objectUnderTest.add(input);

        // Verify
        verifyAll();
    }
}

The issue was resolved by adding the following code to the test class:

@Autowired
private WebApplicationContext context;

@Autowired
private Filter springSecurityFilterChain;

@Before
public void setup() {
    mockMvc = MockMvcBuilders.webAppContextSetup(context)
            .addFilters(springSecurityFilterChain).build();
}

As noted in another answer, if you don't care about the order, you might do best to change the interface so it doesn't care about the order.

If order matters in the code but not in a specific test, you can use the ArgumentCaptor as you did. It clutters the code a bit.

If this is something you might do in multiple tests, you might do better to use appropriate Mockito Matchers or Hamcrest Matchers, or roll your own (if you don't find one that fills the need). A hamcrest matcher might be best as it can be used in other contexts besides mockito.

For this example you could create a hamcrest matcher as follows:

import org.hamcrest.BaseMatcher;
import org.hamcrest.Description;
import org.hamcrest.Matcher;

import java.util.Collections;
import java.util.HashSet;
import java.util.List;
import java.util.Set;

public class MyMatchers {
    public  static <T> Matcher<List<T>> sameAsSet(final List<T> expectedList) {
        return new BaseMatcher<List<T>>(){
            @Override
            public boolean matches(Object o) {
                List<T> actualList = Collections.EMPTY_LIST;
                try {
                    actualList = (List<T>) o;
                }
                catch (ClassCastException e) {
                    return false;
                }
                Set<T> expectedSet = new HashSet<T>(expectedList);
                Set<T> actualSet = new HashSet<T>(actualList);
                return actualSet.equals(expectedSet);
            }

            @Override
            public void describeTo(Description description) {
                description.appendText("should contain all and only elements of ").appendValue(expectedList);
            }
        };
    }
}

And then the verify code becomes:

verify(mockClassB).sendEvent(argThat(MyMatchers.sameAsSet(expectedFileList)));

If you instead created a mockito matcher, you wouldn't need the argThat, which basically wraps a hamcrest matcher in a mockito matcher.

This moves the logic of sorting or converting to set out of your test and makes it reusable.

Perhaps I'm missing something, but why not just do this:

Map.Entry<Integer, Action> entrySet = <whatever you want it to return>
Map mockAvailableActions = mock(Map.class);
when(mockAvailableActions.entrySet()).thenReturn(entrySet);

Also consider whether you actually need a mock Map at all, wouldn't a real one do the job? Mocks are usually used to replace other pieces of your code which you don't want to be involved in your unit test, a Map is part of the core Java language and isn't usually mocked out.

Mockito provides regex matcher in standard org.mockito.Matchers class. Here is an example how this function can be used to verify invocation with proper parameter value:

verify(restMock, times(1)).exchange(matches(".*text=welcome.*to.*blah"), eq(HttpMethod.GET), any(ResponseEntity.class), eq(String.class));

In Mockito 2.1.0 and up with Java 8 you can pass the lambda to argThat out of the box so that one does not need a custom argument matchers. For the example in the OP would be:

verify(mockedFoo).doThing(argThat((Bar aBar) -> aBar.getI() == 5));

This is because as of Mockito 2.1.0, ArgumentMatcher is a functional interface.

Use this :

import static org.mockito.Mockito.verifyZeroInteractions;

// ...

private PrintStream backup = System.out;

@Before
public void setUp() {
    System.setOut(mock(PrintStream.class));
}

@After
public void tearDown() {
    verifyZeroInteractions(System.out);
    System.setOut(backup);
}

I suggest to use Mockito Framework it is very easy to use and understand.

@Mock
private EntityManager entityManager; 

If you want to use any method that belongs to entityManager, you should call.

Mockito.when(METHOD_EXPECTED_TO_BE_CALLED).thenReturn(AnyObjectoftheReturnType);

When you run your test, any call previosly declared in the Mockito.when for the EntityManager will return the value put in the declaration..

Read full documentation here.

https://static.javadoc.io/org.mockito/mockito-core/2.12.0/org/mockito/Mockito.html#stubbing

You can work around this by putting traits in a different package and when testing mock that trait instead of the classes in your sealed jar. That could be construed as a security concern but you can argue against that quite easily.

You could seal a jar that imports all your unsealed code and not add any behavior there. That would give your customer the security he needs, but avoid you having to deal with the restrictions in tests or other implementations where you don't have this requirement.

I'm sure you're using dependencies that are unsealed, so you just make your own testable code a dependency of the sealed jar too.