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 has a recognizable class structure with methods that serve a clear purpose, but readability is undermined by inconsistent formatting. Multiple statements are packed onto single lines, and in some cases multiple actions are combined on one line inside lambdas. The nesting is shallow overall, which is positive, but the lack of spacing between logical blocks makes the flow feel disorganized. The intent of the methods is relatively clear—asserting view names—but the method bodies are compressed, forcing the reader to slow down. While the code is concise, it crosses into being unnecessarily compact. A few simple formatting improvements, like placing each statement on its own line and separating nested blocks with whitespace, would substantially improve readability.
Run 2
The code has clear intent and is logically organized, but suffers from inconsistent formatting that harms readability. Imports are jumbled on one line, some Javadoc and method declarations share lines, and lambda bodies cram multiple statements together. Nesting is minimal, and action granularity is mixed - some lines contain multiple actions. Overall structure and purpose are clear, but visual clutter and inconsistent spacing make it harder to scan than necessary.
Run 3
The code has a logical class structure and clear intent for factory methods, but readability is severely impacted by poor formatting. There are multiple statements on single lines, inconsistent indentation (especially in the first `name` method), and inline comments merged with method signatures. These issues create unnatural reading flow, obscure structure, and violate action granularity. While nesting depth is low and method purposes are understandable, the formatting requires extra effort from the reader to parse the logic. Refactoring with consistent line breaks, one action per line, and proper indentation would significantly improve readability.
Run 1
Code Structure: The class is logically organized around two view-name assertion overloads, but compressed imports and method formatting obscure boundaries. Nesting: Shallow lambda bodies with a single null check are easy to understand. Clarity of intent: Descriptive names, Javadoc, and assertion messages clearly communicate purpose. Code length: The implementation is short and mostly concise, with minor duplication between overloads. Action granularity: Multiple imports, statements, and closing braces share lines, making individual actions harder to distinguish. Reading flow: The conceptual sequence is natural—retrieve the model and view, check for null, then assert—but inconsistent line breaks and inline braces interrupt scanning.
Run 2
Code Structure: The class logically groups two view-name assertion overloads, but compressed imports and method bodies weaken organization. Nesting: Shallow lambda and conditional nesting is easy to understand. Clarity of intent: Descriptive names, documentation, and assertion messages clearly communicate purpose. Code length: The implementation is short and appropriately scoped, though compact formatting sacrifices readability rather than removing unnecessary logic. Action granularity: Multiple imports, statements, and closing braces share lines, making individual actions harder to distinguish. Reading flow: The overall progression is natural, but inconsistent line breaks and a method declaration attached to its documentation interrupt scanning.
Run 3
Code Structure: The class is logically organized around two view-name assertion overloads, but compressed imports and method bodies weaken visual organization. Nesting: Shallow lambda and conditional nesting is easy to understand. Clarity of intent: Descriptive names, Javadoc, and explicit assertion messages clearly communicate purpose. Code length: The implementation is concise without unnecessary logic, although both methods repeat the null check. Action granularity: Multiple imports, declarations, conditionals, assertions, and closing braces share lines, making individual operations harder to distinguish. Reading flow: The conceptual sequence is natural—retrieve the model and view, check for null, then assert the view name—but inconsistent whitespace and crowded statements interrupt scanning.