Common API for MockMvc tests and for real HTTP tests

[spring-projects-issues]

Neil S opened SPR-15081 and commented

There seems to be no common API which can be configure to do mock HTTP tests as well as real HTTP tests.

MockMvc tests suffice during development but for production deployment projects might like to do a complete end-to-end integration test by run real tests against a the (maybe embedded) container sever which will be used in production.

At the moment that means writing the same tests twice using the MockMvc and then TestRestTemplate+assert APIs.

IMHO MockMvc has the friendlier API which results in concise and easier to read test code.

---

Affects: 4.3.5

Issue Links:

• Extract MockHttp from MockMvc [SPR-13818] #18391 Extract MockHttp from MockMvc
• Support varargs for expectations in MockMvc [SPR-16417] #20963 Support varargs for expectations in MockMvc

0 votes, 6 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

I see where you're coming from but for starters a name such as MockMvc would be a misnomer. More importantly by design it is a server-side test framework that simulates running in a Servlet container with the Spring MVC DispatcherServlet and that makes it possible to provide unique value such as whitebox testing -- e.g. assert things like model attributes, handled exceptions, the handler used, and others that couldn't be verified otherwise, and it also allows creating tests that are closer to unit testing such as testing a single controller at a time.

For an integration test with actual HTTP requests the client and server are much more decoupled and there is little unique value I can see us providing over existing tools such as REST Assured.

The general idea is that MockMvc allows you to test thoroughly your Spring MVC controllers and web framework configuration without running a server. Then you should need a lot less full integration testing.

[spring-projects-issues]

Neil S commented

Thanks, all good points.

I do think we ought to have some API which can test both server side and full end to end. Maybe that shouldn't be MockMvc... although I prefer its API over assert and feel that pushing everyone to TestRestTemplate would be a somewhat backward step.

How about a (generically named, say 'MvcTest'?) interface that MockMvc implements, which also has an implementation that makes real HTTP requests?

You're right that this wouldn't provide functionality not already available elsewhere but it would give the ability to reuse potentially huge amounts of code. At the moment I'm having to decide which tests are important enough to run e2e and duplicate the code using TestRestTemplate.

[spring-projects-issues]

Rossen Stoyanchev commented

This looks very promising. I did a quick experiment. Essentially just one extra class that wraps a RestTemplate and applies adaptation to and from the MockHttpServletRequest and MockHttpSevletResponse. Also an interface so test fixtures can be run through MockMvc or the RestTemplate-backed alternative.

I'm going to schedule tentatively for 5.0 RC1 where we are also planning to put together test support for the spring-web-reactive module and this idea here would be useful to flesh out at this time. Thanks for the suggestion!

[spring-projects-issues]

Rossen Stoyanchev commented

/cc robwinch and Andy Wilkinson

[spring-projects-issues]

Neil S commented

Great! Thanks very much :-)

[spring-projects-issues]

Rossen Stoyanchev commented

This needs to be considered together together with #18391 which comes from a different angle but is also about making MockMvc more broadly usable.

A separate concern that needs to be addressed is that many aspects of request building (request + session attributes + anything server-side specific) do not apply to integration tests. How do we deal with that is the question. We could fail fast or ignore those. The same concern is true for expectations matching (model attributes, handler method, etc) but there the matching would naturally fail..

[spring-projects-issues]

Rossen Stoyanchev commented

Note also that in 5.0 we have the WebTestClient which as actual client offers a MockMvc-like API that can be used with or without a server. Another route for addressing this ticket would be adapt it to work with both Spring MVC and WebFlux backends.

[inanemed]

Could you please confirm this is still an issue?

[molexx]

Yes.

@rstoyanchev 's experiment in #19647 (comment) looks to be a good solution.