How to use supports_non_generic_matchers method of org.mockitousage.matchers.CustomMatcherDoesYieldCCETest class

You can implement this test functionality this way (Java 8):

myMock
    .expect(requestTo("http://myfakeurl.blabla"))
    .andExpect(method(HttpMethod.GET))
    .andRespond(request -> {
        try {
            Thread.sleep(TimeUnit.SECONDS.toMillis(1));
        } catch (InterruptedException ignored) {}
        return new MockClientHttpResponse(myJsonResponse, HttpStatus.OK);
    });

But, I should warn you, that since MockRestServiceServer simply replaces RestTemplate requestFactory any requestFactory settings you'd make will be lost in test environment.

Yes, you are on the right track, putting a mock @Bean in a @Configuration class is one approach, and I'll describe my experience:

The trick is that you need to use a different set of .xml files purely for testing which exclude the live versions of those beans.

@ContextConfiguration(locations = {"context1-test.xml", "context2-test.xml", ...})

And the "-test-xml" files go in src/test/resources.

At least that was my experience in doing the same thing. Maybe there is some way to "override" the beans with the mock versions, but as yet I am not aware of it.

I also chose to put the mocks (I had 5 of them) all together in an own configuration:

@Configuration
public class MockServicesProvider {
     @Bean
     public AnotherBean myMock() { return mock(AnotherBean.class); }
}

Another interesting part of this problem is the common usage of initMocks(this); in the @Before method of your test class.

If the mocks are being used in other places (and they are, that's why you are wiring them up...) then initMocks(this) will blow them away between tests (not literally - just that new mocks will be created and any other mocks wired up in other objects will be "lost").

The solution to this was to call mockito's reset(mockObject) in the @Before method before each test. The same mocks are reset (all the when's and interactions), without creating new mocks.

Note that the Mockito docs for reset say very sternly that this method should not commonly be used, except in the context of mocks being applied via dependency injection, as we are indeed doing in this case :)

Have fun!

One way is to use a Captor

ArgumentCaptor<List> captor = ArgumentCaptor.forClass(List.class);
verify(mock).createButtons(captor.capture());
assertEquals(x, captor.getValue().size()); // if expecting single list
assertEquals(x, captor.getValues().size()); // if expecting multiple lists

See #15 for the documentation.

You could also use a custom argument matcher. The documentation shows an example that does exactly what you want:

 class IsListOfTwoElements extends ArgumentMatcher<List> {
     public boolean matches(Object list) {
         return ((List) list).size() == 2;
     }
 }
 
 List mock = mock(List.class);
 when(mock.addAll(argThat(new IsListOfTwoElements()))).thenReturn(true);
 mock.addAll(Arrays.asList("one", "two"));
 verify(mock).addAll(argThat(new IsListOfTwoElements()));

You could, for instance, also add a constructor so you can specify list size desired, etc.

Mocking the iterator works for me. See below code sample:

import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

import java.util.Collection;
import java.util.Iterator;

import org.junit.Before;
import org.junit.Test;

public class TestMockedIterator {

    private Collection<String> fruits;
    private Iterator<String> fruitIterator;

    @SuppressWarnings("unchecked")
    @Before
    public void setUp() {
        fruitIterator = mock(Iterator.class);
        when(fruitIterator.hasNext()).thenReturn(true, true, true, false);
            when(fruitIterator.next()).thenReturn("Apple")
            .thenReturn("Banana").thenReturn("Pear");

        fruits = mock(Collection.class);
        when(fruits.iterator()).thenReturn(fruitIterator);
    }

    @Test
    public void test() {
        int iterations = 0;
        for (String fruit : fruits) {
            iterations++;
        }
        assertEquals(3, iterations);
    }
}

The problem with static methods is they're very hard to fake when they're not relevant to the system you're trying to test. Imagine this code:

public void systemUnderTest() {
    Log.connectToDatabaseForAuditing();
    doLogicYouWantToTest();
}

The connectToDatabaseForAuditing() method is static. You don't care what this method does for the test you want to write. But, to test this code now you need an available database.

If it were not static the code would look like this:

private Logger log; //instantiate in a setter AKA dependency injection/inversion of control

public void systemUnderTest() {
    log.connectToDatabaseForAuditing();
    doLogicYouWantToTest();
}

And your test would be trivial to write without a database now:

@Before
public void setUp() {
    YourClass yourClass = new YourClass();
    yourClass.setLog(new NoOpLogger());

}

//.. your tests

Imagine trying to do that when the method is static. I can't really think of a way except for modifying the logger to have a static variable called inTestMode that you set to true in the setUp() to make sure it doesn't connect to a database.

I've needed this several times as well. I've put together a small sample below, which you'd want to adjust to your needs. Basically, you create your own Appender and add it to the logger you want. If you'd want to collect everything, the root logger is a good place to start, but you can use a more specific if you'd like. Don't forget to remove the Appender when you're done, otherwise you might create a memory leak. Below I've done it within the test, but setUp or @Before and tearDown or @After might be better places, depending on your needs.

Also, the implementation below collects everything in a List in memory. If you're logging a lot you might consider adding a filter to drop boring entries, or to write the log to a temporary file on disk (Hint: LoggingEvent is Serializable, so you should be able to just serialize the event objects, if your log message is.)

import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.log4j.spi.LoggingEvent;
import org.junit.Test;

import java.util.ArrayList;
import java.util.List;

import static org.hamcrest.CoreMatchers.is;
import static org.junit.Assert.assertThat;

public class MyTest {
    @Test
    public void test() {
        final TestAppender appender = new TestAppender();
        final Logger logger = Logger.getRootLogger();
        logger.addAppender(appender);
        try {
            Logger.getLogger(MyTest.class).info("Test");
        }
        finally {
            logger.removeAppender(appender);
        }

        final List<LoggingEvent> log = appender.getLog();
        final LoggingEvent firstLogEntry = log.get(0);
        assertThat(firstLogEntry.getLevel(), is(Level.INFO));
        assertThat((String) firstLogEntry.getMessage(), is("Test"));
        assertThat(firstLogEntry.getLoggerName(), is("MyTest"));
    }
}

class TestAppender extends AppenderSkeleton {
    private final List<LoggingEvent> log = new ArrayList<LoggingEvent>();

    @Override
    public boolean requiresLayout() {
        return false;
    }

    @Override
    protected void append(final LoggingEvent loggingEvent) {
        log.add(loggingEvent);
    }

    @Override
    public void close() {
    }

    public List<LoggingEvent> getLog() {
        return new ArrayList<LoggingEvent>(log);
    }
}

Try to use Mockito or Easymock for mocking service calls. You need to mock only these methods which are actually used - no need to mock every method. You can creat mock object for WebResource class, then mock accept method call.

In @BeforeClass/@Before JUnit test method write something like (Mockito example)

WebResource res = mock(WebResource.class);
when(res.accept(something)).thenReturn(thatWhatYouWant);

Then in your tests you can use res object as if it was real object and call mock method on it. Instead of returning value you can also throw exceptions. Mockito is pretty cool.

You need to move @EnableJpaAuditing annotation to a separate @Configuration class otherwise it will be loaded even for unrelated application slices.

@Configuration
@EnableJpaAuditing
public class JpaAuditingConfiguration {}

@SpringBootApplication class is used as default configuration for all tests with slices so any additional configuration glued to it will affect more tests than you would expect.

This is also well explained in documentation: User Configuration and Slicing

This question is ancient, but Mockito v2.1.0+ now has a built-in feature for this.

verify(mock, description("This will print on failure")).someMethod("some arg");

More examples included from @Lambart's comment below:

verify(mock, times(10).description("This will print if the method isn't called 10 times")).someMethod("some arg");
verify(mock, never().description("This will print if someMethod is ever called")).someMethod("some arg");
verify(mock, atLeastOnce().description("This will print if someMethod is never called with any argument")).someMethod(anyString());