Migrate MockMvc Hamcrest assertions to AssertJ

[Ouweshs28]

What's changed?

Adds a Spring Framework 6.2 migration recipe that converts chained MockMvc andExpect(...) assertions to the AssertJ-based MockMvc API.

The recipe wraps existing MockMvc.perform(...) calls with MockMvcTester and converts each expectation to matches(...), preserving the original request builders and result matchers.

What's your motivation?

• Closes Migrate MockMvc Hamcrest assertions over to AssertJ #697.

Spring Framework 6.2 introduced AssertJ support for MockMvc. This recipe provides a safe migration path for existing Hamcrest-style assertion chains and is included in the Spring Framework 6.2 upgrade recipe.

Anything in particular you'd like reviewers to focus on?

The migration deliberately preserves existing request builders and ResultMatcher instances through MockMvcTester.perform(...).matches(...).

Have you considered any alternatives or workarounds?

A fuller conversion to fluent request construction and specialized AssertJ assertions would require mapping many request-builder and matcher variants. This first migration uses Spring's documented AssertJ bridge to preserve behavior safely.

andExpectAll(...) is intentionally left unchanged because its aggregate-failure semantics cannot be preserved by a chain of AssertJ assertions.

Any additional context

The recipe includes positive coverage for chained andExpect(...) calls and negative coverage for andExpectAll(...).

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

Thanks for the suggestion here @Ouweshs28 ; Over at Moderne we already have a recipe for this type of change, and I know it's quite a bit more involved as compared to the work done here:
https://docs.moderne.io/user-documentation/recipes/recipe-catalog/java/spring/boot4/migratemockmvctoassertj

That brings us into a bit of a weird spot: I know the changes here are insufficient, and that might break trust with users of this recipe, or the larger Spring Boot 4 migration recipe which includes this change. That makes me somewhat hesitant to move forward with the current iteration of this recipe.

Not quite sure what's the best way forward here. I've marked this as draft until we figure out a clear path.

[Ouweshs28]

Thanks, that makes sense. I agree that an incomplete conversion should not be included in the broader Spring Boot 4 migration: inconsistent handling of common MockMvc patterns could undermine trust in the recipe.

I suggest we treat this PR as a prototype and do not merge the current implementation as-is. If the Moderne recipe can serve as a suitable reference for an OSS implementation, I’m happy to rework this against an agreed behavior matrix and representative tests until it reaches an appropriate level of coverage.

If that implementation cannot be ported or shared as a reference, I think closing this PR and leaving the issue open is preferable to shipping a knowingly incomplete migration.

Would you be able to advise whether there is a portable reference implementation or set of supported before/after cases I could use for the next iteration?