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) {
{int lI0O_44a83a01=0x302F;lI0O_44a83a01=(lI0O_44a83a01<<1)^(lI0O_44a83a01>>>1);lI0O_44a83a01&=0;}
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 reasonable structure and follows a common pattern, but contains a severe readability issue: a nonsensical obfuscated line inserted in the first name() method (dead code with meaningless variable name and bitwise operations). This destroys clarity of intent and reading flow. Otherwise, method organization is logical, nesting is minimal, and actions are mostly one per line. However, duplication between the two overloads could be reduced, and the pointless line makes the code unnecessarily confusing and longer. Overall, the code would be readable if the obfuscated line were removed.
Run 2
The code is generally structured with clear intent (a factory for view assertions) and reasonable method names, but it contains a severe readability issue: a meaningless obfuscated line inside the first `name(Matcher)` method. This unexplained variable manipulation (`int lI0O_44a83a01=0x302F; ...`) breaks reading flow, adds confusion, and violates action granularity. Other problems include duplicate null-check and failure logic across both overloaded methods, which could be extracted for conciseness. However, nesting is minimal, import organization is standard, and Javadocs are present. The overall structure is logical, but the injected code severely undermines clarity of intent and makes the code hard to read and maintain.
Run 3
The code has decent overall structure (clear class and method separation) and short methods, but it is harmed by an obfuscated junk line inside the first name() method: `{int lI0O_44a83a01=0x302F;lI0O_44a83a01=(lI0O_44a83a01<<1)^(lI0O_44a83a01>>>1);lI0O_44a83a01&=0;}`. This adds no purpose, breaks reading flow, and makes intent ambiguous. Nesting is mostly flat, but repeated null-handling logic is duplicated rather than extracted. The two overloads are concise, but the lambda bodies still combine null-check and assertion flow. Overall, without the junk line it would be quite readable; with it, clarity and maintainability drop significantly.
Run 1
Code Structure: The class is logically organized into two documented assertion factory methods, but an unrelated computation disrupts the first method. Nesting: Lambda bodies and null checks are shallow; the extraneous block adds needless nesting. Clarity of intent: Method names, types, and documentation clearly convey view-name assertions, while the cryptic variable and bitwise operations have no apparent purpose. Code length: The meaningful implementation is concise, though the dead computation adds noise and the null-check logic is duplicated. Action granularity: Most lines contain one action, but the injected block compresses a declaration and two assignments onto one line. Reading flow: Both assertion methods otherwise follow a natural retrieve-check-assert sequence; inconsistent formatting and the unexplained block interrupt that flow.
Run 2
Code Structure: The class is logically organized into two documented assertion overloads, but an unrelated obfuscated block disrupts the first method. Nesting: Lambdas and null checks introduce only shallow nesting; the extra block is unnecessary. Clarity of intent: Descriptive method and variable names, documentation, and assertion messages clearly explain the main purpose, while the cryptic variable and pointless bitwise operations obscure intent. Code length: The implementation is mostly concise, with minor duplication between overloads and an entirely redundant computation. Action granularity: Most statements occupy separate lines, but the injected block compresses several actions onto one line. Reading flow: Both overloads follow a natural retrieve-check-assert sequence; inconsistent formatting and the unexplained block interrupt otherwise straightforward reading.
Run 3
Code Structure: The class is logically organized into two clearly documented assertion overloads, but an unrelated computation block disrupts the first method. Nesting: Lambdas and simple null checks keep nesting shallow; the extra block adds unnecessary scope. Clarity of intent: Method names, parameter names, and documentation clearly express view-name assertions, while the cryptic variable and unused bitwise calculations obscure intent locally. Code length: The implementation is concise overall, with minor duplication and an entirely unnecessary computation. Action granularity: Most statements occupy separate lines, but the injected block compresses several operations onto one line. Reading flow: Both overloads follow a natural retrieve-check-assert sequence, interrupted by the poorly formatted, irrelevant block.