Rename AssertableMockMvc to MvcTester and review assertions structure

[snicoll]

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:

• The request and the response
• What handler handled the request, and the ModelAndView if any
• A resolved exception if the processing failed and an exception handled handled it

AssertableMvcResult expands on the latter by providing the unresolved exception as well, rather than throwing a checked exception as MockMvc does.

This class can then be fed to AssertJ and we can then navigate on various pieces of the result:

assertThat(result).hasStatusOk()
assertThat(result).body()...
assertThat(result).headers()...
assertThat(result).cookies()...
assertThat(result).model()...
assertThat(result).handler()...

There are two things we'd like to explore here:

1. We want users to assign the result of perform so that they can run multiple asserts against the result. The name AssertableMvcResult is a bit off putting so we should consider renaming it
2. If we did then we should investigate the possiblity of exposing a MvcResult than extending MvcResult. This may allow us to navigate to more structured part of the result, such as:

assertThat(result.body())...
assertThat(result.headers())...

paging @philwebb and @simonbasle who helped me brainstorm on this.

[snicoll]

We've made quite a bit of progress here, focusing on the renaming bit of it. We came to the following proposal:

• Entry point named 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)
• Result 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

[odrotbohm]

I've applied those upgrades to the sample project I had on M1. As can be seen in this commit, this indeed improves the code to be written in some places.

That said, it actually introduces more boilerplate in many places, as there's now a ….getMvcResult().… (called on something that already is a result) to be inserted everywhere one could previously obtain the response directly. Also, the code doing JSON Path verifications looks more slightly more complicated now.

If you look at the diff overall, it really shows that the previously concise declaration (one fluent statement verifying and producing a result) now has to be scattered into assignment, assertions, and the very same two-levels-deep lookup.

[snicoll]

Thanks for trying the update.

The missing getResponse and getRequest on MvcTestResult is an oversight. I've fixed that in #32846.

Also, the code doing JSON Path verifications looks more slightly more complicated now.

That's not an equivalent of what you had before. What you had before is:

.body().jsonPath().extractingPath("$.status").isEqualTo("Delivered");

The equivalent after this issue is:

.bodyJson().extractingPath("$.status").isEqualTo("Delivered");

I guess it looks more complicated as you're trying to build a single assertion statement irrespective of how complicated it may or may not be. This issue didn't mean to address that I am afraid (as we've established several times).

it really shows that the previously concise declaration (one fluent statement verifying and producing a result) now has to be scattered into assignment, assertions, and the very same two-levels-deep lookup.

Assignment and assertions are to be expected, that's just how AssertJ works and return assertThat(...) is not something you should be doing anyway.

I still have this pattern of returning a new assert object based on a function on my radar. That would allow you to chain multiple invocations where the next request can be triggered based on the response of the previous one. We've tried several API changes based on your tests but couldn't find anything that we find satisfactory so far.