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
This code is highly readable. The package and imports are clearly organized. The class has a single, well-documented purpose: creating view name assertions. The structure is flat, with minimal nesting—only a null check inside each lambda. Intent is clear from descriptive method names and Javadoc. The length is concise; no unnecessary code exists. Each lambda performs one logical action per line: retrieving the ModelAndView, checking for null, and then performing the assertion. The reading flow is natural: the public API methods are defined first, followed by their implementations, and comments explain non-obvious details like the protected constructor.
Run 2
The code is highly readable with clear structure, minimal nesting, and concise methods. Each method has a single responsibility and follows a consistent pattern: retrieve ModelAndView, check for null, then assert. The Javadoc comments clarify intent without being excessive. Action granularity is appropriate—one logical action per line. The reading flow is natural, moving from guard clause to assertion. Minor deductions: the duplicate null-check logic could be extracted to a helper method to reduce repetition, and the lambda parameter name 'result' is slightly generic. Overall, the code is well-organized, flat, and unambiguous.
Run 3
This code is highly readable. It has a clear, logical structure with a protected constructor and two well-documented factory methods. Nesting is minimal—only a single level of lambda and conditional, avoiding deep indentation. Intent is explicit through method names and comprehensive Javadoc, clearly explaining the purpose of each assertion. Code length is concise without being overly terse; each method performs a single, well-defined task. Action granularity is appropriate: object retrieval, null check, and assertion are on separate lines, making each step easy to follow. Reading flow is natural, moving from setup to validation, with consistent formatting and clear naming conventions. Minor improvements could include extracting repeated null-check logic, but overall the code is clean, maintainable, and easy to understand.
Run 1
Code Structure: Logically organized as a small assertion factory with two clearly related overloads. Nesting: Shallow; each lambda contains only a simple null check. Clarity of intent: Descriptive class and method names, Javadoc, and assertion messages make the purpose clear, although 'mav' is slightly abbreviated. Code length: Concise overall, with minor duplication of ModelAndView retrieval and validation. Action granularity: Each statement performs one action, making operations easy to follow. Reading flow: Consistent formatting and a natural retrieve-check-assert sequence support smooth reading; import grouping and extra blank lines could be polished.
Run 2
Code Structure: The class is logically organized, with a constructor and two closely related assertion overloads. Nesting: Each lambda contains only a single shallow null check. 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: The implementation is concise, though both overloads repeat the ModelAndView retrieval and null check. Action granularity: Each statement performs one clear action. Reading flow: Both methods follow a natural retrieve-check-assert sequence and use consistent formatting. Minor spacing issues around imports and the constructor slightly reduce polish but do not hinder comprehension.
Run 3
Code Structure: The class is logically organized around two clearly documented overloads for view-name assertions. Nesting: Each method contains only a lambda and a simple null check, keeping nesting shallow. Clarity of intent: Descriptive method signatures, assertion messages, and Javadoc make the purpose clear; the abbreviation 'mav' is slightly less explicit than 'modelAndView'. Code length: The implementation is concise, though the repeated ModelAndView retrieval and null check introduce minor duplication. Action granularity: Each statement performs one clear action on its own line. Reading flow: Both methods follow the same natural retrieve-check-assert sequence, making them easy to scan and compare. Minor formatting issues, including tightly grouped imports and extra blank lines, slightly reduce polish.