Source code
package org.springframework.test.web.servlet.result;
import org.hamcrest.Matcher;
import org.springframework.test.web.servlet.ResultMatcher;
import org.springframework.web.servlet.ModelAndView;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.springframework.test.util.AssertionErrors.assertEquals;
import static org.springframework.test.util.AssertionErrors.fail;
/**
* Factory for assertions on the selected view.
*
* <p>An instance of this class is typically accessed via
* {@link MockMvcResultMatchers#view}.
*
* @author Rossen Stoyanchev
* @since 3.2
*/
public class ViewResultMatchers {
/**
* Protected constructor.
* Use {@link MockMvcResultMatchers#view()}.
*/
protected ViewResultMatchers() {
}
/**
* Assert the selected view name with the given Hamcrest {@link Matcher}.
*/
public ResultMatcher name(Matcher<? super String> matcher) {
return result -> {
ModelAndView mav = result.getModelAndView();
if (mav == null) {
fail("No ModelAndView found");
}
assertThat("View name", mav.getViewName(), matcher);
};
}
/**
* Assert the selected view name.
*/
public ResultMatcher name(String expectedViewName) {
return result -> {
ModelAndView mav = result.getModelAndView();
if (mav == null) {
fail("No ModelAndView found");
}
assertEquals("View name", expectedViewName, mav.getViewName());
};
}
}
Run 1
The code demonstrates excellent readability. Structure is logical with clear package, imports, and class organization. Nesting is minimal - only a single-level lambda with a null check. Intent is unambiguous through descriptive method names and Javadoc. Code length is concise, avoiding unnecessary boilerplate. Action granularity is appropriate - each assertion is on its own line. Reading flow is natural, following a predictable pattern. Minor deductions: protected constructor could be private, and the null check is slightly repetitive across methods, but these are negligible.
Run 2
The code is highly readable. It has a clear, logical structure with well-organized imports, class-level Javadoc, and two concise methods. Nesting is minimal—each method contains a simple lambda with a single null check, keeping the logic flat and easy to follow. The intent of each method is explicit: one asserts a view name against a Hamcrest matcher, the other against an exact string. Code length is appropriate, avoiding unnecessary verbosity while maintaining clarity. Each action (retrieving ModelAndView, checking null, asserting) is placed on its own line, improving granularity. The reading flow is natural—factory method, lambda execution, validation, then assertion. Minor deductions: duplicated null-check logic in both methods could potentially be extracted for reuse, and the static imports slightly reduce local context clarity, but overall the code is clean and maintainable.
Run 3
The code is highly readable with a clean, logical structure. It follows standard Java conventions with clear package, imports, and Javadoc documentation. The class has a single responsibility: providing view-related result matchers. Each method is concise, has a clear purpose, and uses lambda expressions to keep the code flat and avoid deep nesting. Error handling is handled gracefully with an early exit if ModelAndView is null, preventing nested conditionals. Action granularity is respected—each lambda body performs one logical assertion after a null check. Reading flow is natural, moving from method signature to validation to assertion. The minimal use of static imports improves clarity, and the concise implementation avoids unnecessary verbosity.
Run 1
Code Structure: The class is logically organized around two closely related assertion overloads, with a clearly documented constructor. Nesting: Each method has only a lambda and a simple null check, keeping nesting shallow. Clarity of intent: Javadoc, descriptive method parameters, and explicit assertion messages make the purpose clear; the abbreviation 'mav' is slightly less descriptive than 'modelAndView'. Code length: The implementation is concise, although the two overloads repeat the retrieval and null-check logic. Action granularity: Each statement performs one clear action on its own line. Reading flow: Both methods follow the same natural sequence: retrieve the model and view, validate its presence, then assert the view name. Minor formatting issues, such as tightly grouped imports and extra blank lines, do not significantly impede readability.
Run 2
Code Structure: Well-organized class with two focused overloads and useful documentation. Nesting: Shallow lambda bodies with a single null check are easy to follow. Clarity of intent: Descriptive method signatures, assertion messages, and Javadoc clearly communicate the purpose; the abbreviation 'mav' is slightly less explicit than 'modelAndView'. Code length: Concise overall, though the null-check logic is duplicated across overloads. Action granularity: Each statement performs one clear action on its own line. Reading flow: Both methods follow the same natural sequence—retrieve the model and view, check its presence, then assert the view name. Minor spacing inconsistencies around imports and the constructor do not materially hinder readability.
Run 3
Code Structure: The class is logically organized, with a documented constructor and two closely related assertion methods. Nesting: Each method contains only a lambda and a simple null check, keeping nesting shallow. Clarity of intent: Class documentation, method names, parameter names, and assertion messages clearly communicate the purpose; the abbreviation 'mav' is a minor clarity drawback. Code length: The implementation is concise, though model retrieval and null checking are duplicated across overloads. Action granularity: Each statement performs a single clear action. Reading flow: Both methods follow the same natural sequence—retrieve the model and view, check its presence, then assert the view name. Minor formatting issues, including tightly grouped imports and extra blank lines, slightly reduce polish.