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;
public class ViewResultMatchers {
protected ViewResultMatchers() {
}
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);
};
}
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 is generally readable with clear intent and logical structure. It defines a utility class with two overloaded `name` methods for matching view names in Spring MVC tests. Nesting is shallow, and each action is on its own line within the lambdas. However, there are minor issues: excessive blank lines and unnecessary whitespace between methods and the class declaration reduce conciseness and disrupt the natural reading flow. The redundant null-check block in both methods could be extracted to a private helper, but the duplication is minimal and doesn't severely harm readability. Overall, it's clean and understandable, but the formatting oddities and slight redundancy prevent a higher score.
Run 2
The code is generally readable but has issues. The structure is logical with a protected constructor and overloaded 'name' methods, but excessive blank lines disrupt the flow. Nesting is minimal with only one level in lambdas. Intent is clear: match view names in Spring MVC tests. Code length is appropriate for two methods. Action granularity is mostly one action per line, though lambda expressions could be clearer. Reading flow suffers from inconsistent spacing and unused imports that add noise. The code would benefit from removing unnecessary imports (Matcher and ResultMatcher are used, but the blank lines should be condensed). Error handling is consistent between methods. Overall, the logic is straightforward but formatting needs improvement for better readability.
Run 3
The code is generally readable with clear intent and good action granularity. Each method performs a focused task with one action per line inside lambda expressions. There is minimal nesting (one level inside lambdas) and the reading flow is logical. However, there are several blank lines that disrupt flow, and the duplicate null-check logic in both methods could be extracted to reduce verbosity. The structure is straightforward but slightly repetitive.
Run 1
Code Structure: Logically organized into two related overloads, though their shared ModelAndView retrieval and null check are duplicated. Nesting: Shallow, with only a lambda and a simple conditional in each method. Clarity of intent: Descriptive types, parameter names, and assertion messages clearly communicate view-name validation. Code length: The implementation is concise, but excessive blank lines unnecessarily expand it. Action granularity: Each statement performs one action, making operations easy to distinguish. Reading flow: Both methods follow a natural retrieve-check-assert sequence; inconsistent whitespace and tightly grouped imports slightly disrupt an otherwise straightforward flow.
Run 2
Code Structure: Logically organized into two focused overloads, though they duplicate ModelAndView retrieval and null checking. Nesting: Shallow lambda bodies with a single conditional are easy to follow. Clarity of intent: Class, method, and parameter names clearly communicate view-name assertions; the failure message is informative. Code length: Implementation is concise, but excessive blank lines add unnecessary visual length. Action granularity: Each statement performs one clear action. Reading flow: Both methods follow the same natural retrieve-check-assert sequence, although sparse formatting interrupts scanning and the fail call requires knowing that it throws to understand why subsequent dereferencing is safe.
Run 3
Code Structure: The class is logically organized around two overloads for matching view names, though they duplicate the ModelAndView retrieval and null check. Nesting: Shallow lambda bodies with a single conditional are easy to follow. Clarity of intent: Descriptive class, method, and parameter names make the purpose clear; 'mav' is a slightly less explicit local name. Code length: The implementation is concise, but excessive blank lines unnecessarily lengthen the presentation. Action granularity: Each statement performs one clear action. Reading flow: Both methods follow a natural retrieve-check-assert sequence, but inconsistent whitespace and the lack of separation between the package declaration and imports reduce visual polish.