Closed snicoll closed 1 week ago
We've made quite a bit of progress here, focusing on the renaming bit of it. We came to the following proposal:
MockMvcTester
(formerly known as AssertableMockMvc
). After having considered several names and the fact that a reference to MockMvc and AssertJ can be desirable, we rather think that a pattern for the 2024 API review of things (à la *Client
for production code) could be a way out. We think that *Tester
could be such suffix. We still want to hint at MockMvc
even if the actual implementation is mostly hidden (so it's rather a conceptual reference)MvcTestResult
(formerly AssertableMvcResult
) It doesn't extend from MvcResult
but provides access to it. That's actually very important as folks upgrading to the new infrastructure may keep a reference to MvcResult
that would have compiled but not giving any AssertJ capable support then.Irrespective of this issue, we've reviewed of the API and found several shortcuts to be desirable, as well as avoid a double navigation for the body.
This proposal is available at https://github.com/snicoll/spring-framework/tree/mvctester-review
When we perform a request with MockMvc, we get a
MvcResult
that contains all the elements we need to assert that the processing of the request went well, such as:AssertableMvcResult
expands on the latter by providing the unresolved exception as well, rather than throwing a checked exception asMockMvc
does.This class can then be fed to AssertJ and we can then navigate on various pieces of the result:
There are two things we'd like to explore here:
AssertableMvcResult
is a bit off putting so we should consider renaming itMvcResult
than extendingMvcResult
. This may allow us to navigate to more structured part of the result, such as:paging @philwebb and @simonbasle who helped me brainstorm on this.