Develop Reference

Spring Test Module vs Mockito

I am learning about integration testing a spring app that communicates with a rest API. I found out from this article that spring test supports two ways to do, what I assume the same thing.
Create a mockserver using MockRestServiceServer
Create a mock object using Mockito
I understand that the former intercepts http request; then returns the objects, while the latter returns the object directly without bothering with any http requests at all.
Since in the end, at least in most cases, we just verify the object retrieved and compare it to the expected result.
So, my Questions; if try to compare:
What are possible trade-offs; if I choose either one of them?
Are there any advantages of choosing one than the other?
For which cases would I prefer one compared to the other (possible
use cases of each)?

Mockito mocks out all internal part of restTemplate and just returns responses to method directly.
MockRestServiceServer lets restTemplate to run all the things before httpClient call.
It means you will test error handling, mapping etc with MockRestServiceServer.

Is it possible to make a real integration test with JerseyTest?

There are many pages on the net, declaring that they describe the creation of integration tests with JerseyTest. Such as:
https://blog.codecentric.de/en/2012/05/writing-lightweight-rest-integration-tests-with-the-jersey-test-framework/
But notice! It is not an integration test really. It mocks the whole service under the API function. So, it is a unit test. And all examples for 'integration' tests that I had found, are such mocking stubs.
And I want to create a really integration test, I want to send a JSON string and get back another JSON string (or HTML). Of course, for that Jersey in coordination with JerseyTest should collaborate somehow to create a request, call my API function, follow it to the DB queries, fulfil them, and return a response that I can assert by parts.
How can I do it? (If it is possible, of course)

Testing a Jersey Client wrapper

I am trying to write a test for an API client that uses Jersey Client to make the requests.
I wanted to fake a certain server response to return a pre-captured json string.
Eg.
client().resource("/recommendations").queryParam("username", karan").get(Recommendation.class)
should return the appropriate class based on a json string I have stored in a file.
How can I fake that? Or would I have to instantiate a fake server to return the actual json, and let the jersey client to do it's work?
Thanks

One popular solution is to use a testing framework like EasyMock or Mockito to create a mock Jersey client which expects specific method calls and returns predefined data (e.g. json). The mock is then injected into the API client in place of the real Jersey client.
In general, you can also avoid the frameworks by creating the mock yourself, i.e. subclassing the client and overriding methods you expect to call, to return predefined data. Then pass your mock into the API client as a constructor argument. Whether or not you justify a framework depends on how much mocking you expect to need, which is determined in part by how many external dependencies you have.

Unit testing of Servlets

I need to write unit test around a function which takes HttpServletRequest and HttpServletResponse object as an argument.
If I create the mock of these two object(request and response), how change in one will reflect in another.
Ex. If I want to unit test around the code where I am setting the header in response object.
response.addHeader("X-UA-Compatible", "IE=EmulateIE7");
Let me know how to proceed .

In your mocking library there will be some way to assert that a method has been invoked. So, your test code would include a statement such as:
// psuedo-code
assertThat(mockResponse).addHeader("X-UA-Compatible", "IE=EmulateIE7");
In the mocking frameworks I have used (JMock, Mockito), there is no automatic co-operation between mocked objects. So your mocked HttpServletRequest will have no relationship to your mocked HttpServletResponse unless you declare one.

The Spring Framework provides both a MockHttpServletRequest and a MockHttpServletResponse.

The problem is with standard mocks, they will create you a proxy. So you may never know if the correct value was set after the code calls
response.addHeader("X-UA-Compatible", "IE=EmulateIE7");
If you create the stub yourself then you can actually verify what was set in the method call. But this approach has many problems as well.

Do I need to unit test web service request dispatcher (Java)?

This class is simply a request dispatcher. It takes request and response objects, and pass down the work according the request type. Application logic is tested. Mocking has to be avoided. How can I write unit test for this dispatcher without turning the test into integration or system test? How are dispatchers usually tested?
EDIT: I was told to avoid mocking. I don't think I can change that decision.

There should be two parts to the code; the first is the marshalling of data between the web layer and dispatching, the second is dispatching to handlers.
Dispatching can be tested using "plain" unit testing, it's just logic to map arbitrary criteria to handlers.
The marshalling layer requires either mocking, or enough integration to create a web request and watch its routing, what's returned from its handler, etc. HtmlUnit is one solution, there are a ton of others.

Use mocks. Do the unit tests.
If you start picking and chosing which parts to test and what not to test, you might as well not test anything at all.
Then again, you might just name them "Bootstraps" or "Imposter" or some other name and get around the restrictions. Alternative, you might be able to hand-code the mocked objects and get around the restrictions that way.