We\'re trying to set up Spring-Test-MVC for our Spring-MVC web app. We started out using freemarker and everything was fine. We decided against it though and are now trying
I have created a modified version of MockRequestDispatcher that builds the same chain as MockMvc and passes the request to that chain for forward requests. That fixes this issue for me. Some more work has to be done if the view is rendered outside of the dispatcher servlet (e.g. via jsp).
The code is there: https://gist.github.com/micw/a8b20720db900762a29d
Most work was to inject it at the right place. I did this my creating a RequestPostProcessor for MockMvc and some mockito-magic that intercepts the MockHttpServletRequest.getRequestDispatcher call.
To use it, add it to your test classpath and call it directly after creating your MockMvc instance:
mvc = MockMvcBuilders.webAppContextSetup(webApplicationContext)
[...]
.build();
WebMvcRequestDispatcherForwardFix.apply(mvc);
@Biju -- I appreciate this answer and it saved me a trip, and I'm not trying to shoot the messenger here, but I must say for the benefit of anyone on the Spring team who might be motivated to build something better, I'm finding MockMVC to be pretty much an exercise in triviality and futility. First, Spring authentication is not directly supported. OK fair enough if you scout StackOverflow you can find a workaround to that. Then on my own I found that if you have in your spring context configuration, every path you can make up comes back as "OK" even if it should return "notFound". OK, whatever, take that out and let us never speak of it again. :) And now come to find out that MockMVC is really only MockMC -- no view processing takes place. So at the end of the day what this software is good for is testing applications that contain neither security nor views -- which would be, what, exactly, toy JSON applications?
And this is not really an answer, it's a rant, which means now MockMVC is going to cost me StackOverflow reputation too! :) Hulk smash!
[EDIT] -- OK rant aside it does look like there are ways around this. [LATER EDIT] Unfortunately the way around this I found is no longer available.
Adding onto your edit3, essentially for JSP rendering the final call is
RequestDispatcher requestDispatcher = httpRequest.getRequestDispacher(jspPath)
requestDispatcher.forward(httpRequest,httpResponse)
and the RequestDispatcher
implementations are provided by the container (since it is dependent on how the jsp's need to be compiled, where to place the compiled jsp's etc). The Mock implementation of RequestDispatcher simply captures the forwarded JSP page, and you can only validate that the path to the JSP is what you expect it to be.