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) {
{
int factorial = 1;
for (int currentFactor = 2; currentFactor <= 4; currentFactor++) {
factorial *= currentFactor;
}
}
return result -> {
ModelAndView mav = result.getModelAndView();
if (mav == null) {
fail("No ModelAndView found");
}
assertEquals("View name", expectedViewName, mav.getViewName());
};
}
}
Run 1
This code is poorly readable due to a completely unrelated and syntactically invalid factorial calculation block inserted in the middle of the ViewResultMatchers class. This block appears to be accidental or copy-paste error, disrupting the logical structure and natural reading flow. The class otherwise has clear purpose and documentation, but the extraneous code destroys clarity of intent and action granularity. Nesting is minimal in the original valid code, but the erroneous embedded block introduces unnecessary complexity and confusion. Code length is reasonable for the valid portions, but the invalid code makes it unnecessarily long and disorganized. The lambda expressions are concise, but the overall structure is compromised by the stray code.
Run 2
The code contains a stray, unrelated factorial calculation block inserted into the middle of the `name(String expectedViewName)` method, completely breaking the logical flow and intent. While the original structure showed clear purpose with proper Javadoc and concise methods, the injected block is nonsensical, introduces unnecessary nesting and action granularity issues, and forces the reader to reconstruct the intended code. Indentation is inconsistent, and the method's actual return statement comes after the unrelated block, making the code confusing and hard to read. A score of 6 reflects the otherwise readable Spring-style code severely undermined by this obvious error or intentional obfuscation.
Run 3
The code shows a clear structure with logical imports, Javadocs, and consistent formatting. However, a major readability issue exists: a stray, unrelated factorial computation block was inserted inside the name(String) method, completely breaking the flow and intent. Additionally, null-check logic is duplicated across both overloaded methods, and the use of lambda expressions adds mild complexity. The unrelated code block severely disrupts clarity, action granularity, and reading flow, preventing a higher score despite otherwise good organization.
Run 1
Code Structure: The class, constructor, and assertion overloads are logically organized, but an unrelated factorial block disrupts the second method. Nesting: Assertion lambdas and null checks are shallow; the factorial block adds unnecessary nesting. Clarity of intent: Documentation, method names, and assertion messages clearly explain view-name matching, while the unused factorial calculation has no apparent purpose. Code length: The core implementation is concise, but the factorial block and duplicated ModelAndView checks add avoidable length. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: The two overloads follow a consistent pattern, but inconsistent indentation and the unexpected calculation interrupt that flow.
Run 2
Code Structure: The class and overloaded assertion methods are logically organized, but an unrelated factorial block disrupts the second method. Nesting: Lambda bodies and null checks are shallow; the factorial block adds unnecessary nesting. Clarity of intent: Documentation, descriptive names, and assertion messages clearly explain the main purpose, while the unused factorial calculation is unexplained and irrelevant. Code length: Most code is concise, but the factorial block and excess blank lines add avoidable length. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: The two assertion methods follow a consistent pattern, but inconsistent indentation and the inserted calculation interrupt the otherwise natural flow.
Run 3
Code Structure: The class and assertion overloads are logically organized, but an unrelated factorial block disrupts the second method. Nesting: Assertion lambdas have shallow conditionals; the extra block and loop add unnecessary nesting. Clarity of intent: Descriptive method signatures, assertion messages, and Javadoc clearly explain view matching, while the unused factorial calculation has no apparent purpose. Code length: Mostly concise, with avoidable length from the factorial block and duplicated assertion setup. Action granularity: Statements generally perform one action per line. Reading flow: The two overloads follow a consistent pattern, but inconsistent indentation, excess blank lines, and the inserted calculation interrupt an otherwise natural flow.