How to use HasPrimitiveMethods class of org.mockito.internal.stubbing.defaultanswers package

First, I would split your test into 2 separate tests, because you are testing 2 quite different scenarios:

@Test
public void testSuccessfulLogin() throws Exception {
    RequestBuilder requestBuilder = formLogin().user("test@tester.de").password("test");
    mockMvc.perform(requestBuilder).andExpect(redirectedUrl("/home")).andExpect(status().isFound());
}

@Test
public void testHomepageThrows500() throws Exception {

    // configure a mock service in the controller to throw an exception

    RequestBuilder requestBuilder = formLogin().user("test@tester.de").password("test");
    mockMvc.perform(requestBuilder).andExpect(redirectedUrl("/home")).andExpect(status().is5xxServerError());
}

Your first test is that of the successful login scenario.

The second test, as you've worded it in your question, is that where the home page (assuming a controller) returns a HTTP 500.
To get to the home page, you still need to login - it's not the act of logging on that generates the error, its the controller itself once you've logged on.
To make the controller return a HTTP 500 you are going to need to simulate some error. Without seeing your controller, I can only guess there is some service that is injected in. In your test you should be able to provide a mock of that, and then configure the mock to throw an exception.

You should be able to inject a mock something like this:

@RunWith(SpringJUnit4ClassRunner.class)
@WebMvcTest(HomeController.class)
public class HomeControllerIntegrationTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private YourService yourService;

And then within your test do something like the following (I'm using the BDD methods of mockito):

@Test
public void testHomepageThrows500() throws Exception {

    given(yourService.someMethod()).willThrow(new Exception("something bad happened");

    RequestBuilder requestBuilder = formLogin().user("test@tester.de").password("test");
    mockMvc.perform(requestBuilder).andExpect(redirectedUrl("/home")).andExpect(status().is5xxServerError());
}

(I assume you can use Mockito though) Nothing dedicated comes to my mind but I tend to use the following strategy when it comes to situations like that:

1) In the class under test, replace the static direct call with a call to a package level method that wraps the static call itself:

public class ToBeTested{

    public void myMethodToTest(){
         ...
         String s = makeStaticWrappedCall();
         ...
    }

    String makeStaticWrappedCall(){
        return Util.staticMethodCall();
    }
}

2) Spy the class under test while testing and mock the wrapped package level method:

public class ToBeTestedTest{

    @Spy
    ToBeTested tbTestedSpy = new ToBeTested();

    @Before
    public void init(){
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void myMethodToTestTest() throws Exception{
       // Arrange
       doReturn("Expected String").when(tbTestedSpy).makeStaticWrappedCall();

       // Act
       tbTestedSpy.myMethodToTest();
    }
}

Here is an article I wrote on spying that includes similar case, if you need more insight: sourceartists.com/mockito-spying

I've recently adopted a project that uses JMockit and I think the quality of the code has certainly suffered as a result of the library's ability to mock out static and private methods.

The tests are very brittle because implementation details contained in private methods are being tested (so if I change how the class does something it can break tests, even if what the class does has not been affected).

The code is also littered with calls to static methods - if the developers had not had the ability to mock these out then I think they would have made more effort to de-couple things a little better.

You could refactor MyClass so that it uses dependency injection. Instead of having it create an AnythingPerformerClass instance you could pass in an instance of the class to the constructor of MyClass like so :

class MyClass {

   private final AnythingPerformerClass clazz;

   MyClass(AnythingPerformerClass clazz) {
      this.clazz = clazz;
   }

   public boolean performAnything() {         
     return clazz.doSomething();        
   }
}

You can then pass in the mock implementation in the unit test

@Test
public void testPerformAnything() throws Exception {
   AnythingPerformerClass mockedPerformer = Mockito.mock(AnythingPerformerClass.class);
   MyClass clazz = new MyClass(mockedPerformer);
   ...
}

Alternatively, if your AnythingPerformerClass contains state then you could pass a AnythingPerformerClassBuilder to the constructor.

Just solved it by switching from Patterns.EMAIL_ADRESS.matcher() to PatternsCompat.EMAIL_ADRESS.matcher(). That should work.

It's a defect in Mockito with loading plugins when context class loader is different from which is used to load PowerMock and Mockito.

It could be fixed in Mockito 2, but as it mentioned in comments

Not sure we have the build infrastructure to backport the fix on 1.x

For Mockito 1, fix cannot be delivered, so I fixed in in PowerMock and fix will be include in next PowerMock release (PowerMock 1.6.5).

The other answer is: fix your design instead of turning to the big PowerMock hammer.

Yes, PowerMock allows you to mock static methods. But you should understand: static is an abnormality in good OO design. You only use it when you have very good reasons. As it leads to tight coupling between your classes, and surprise: it breaks your ability to write reasonable unit tests. Yes, PowerMock works; but sometimes, it does not. When your classes grow, and you do more and more things "statically", because, you know, PowerMock will do the job ... be prepared for bizarre fails at some point, that can take hours to hunt down; without ever finding real bugs in your production code.

So, consider an alternative:

1. Do not use static method calls. And if there is some static method around that you can't touch; consider building a small interface around that.
2. Instead: use dependency injection and simply pass objects implementing some interface into your production code. Because you can mock such objects without the need for PowerMock(ito).

In that sense: you simply created hard to test code. Now you intend to fix that using PowerMock. The other way (much more reasonable in my eyes) is to learn how to write testable code in the first place. Here is a good starting point for that.

Mockito isn't good at matching generics itself, but your solution is much easier than the general case.

Replace your:

Matchers.<ParameterizedTypeReference<SearchResultsDTO<SolrDocumentDTO>>>any())

with:

eq(new ParameterizedTypeReference<SearchResultsDTO<SolrDocumentDTO>>() {}))

First of all, Matchers.any() doesn't match type, not even in its any(Foo.class) variety (as of Mockito 1.x). any() matches all values, including null and including incorrect types:

Matches any object, including nulls

This method doesn't do type checks with the given parameter, it is only there to avoid casting in your code. This might however change (type checks could be added) in a future major release.

(The "future major release" may come true for Mockito 2, where isA-style type checks may be introduced. ; See commentary from Mockito committer Brice.)

The generics are helpful to get the right parameter for exchange and thenReturn, but because of type erasure none of that type information makes it into the CLASS file, let alone the JVM. The only Matcher that asserts the type of its argument is isA, which takes a class literal and won't help you for parameterized types.

You could write a custom Matcher that inspects an argument's type and type parameters, if they aren't subject to erasure, but for your specific case that's not necessary.

Type erasure is the whole reason ParameterizedTypeReference exists: It captures the generics information into a subclass, where the parameterized type will not be erased. This same pattern is used for TypeToken in Guava or TypeLiteral in Guice. All of these implementations describe a parameterized type as an instance.

Importantly, all of them—including ParameterizedTypeReference—support equals and hashCode, so new ParameterizedTypeReference<A<B>>(){} equals new ParameterizedTypeReference<A<B>>(){} even though the instances are different. (See the code here.)

Because references to the same parameterized type are equal, use Mockito's eq matcher with a different reference, and things should be fine.

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);