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() {
if (((0x24BC ^ 0x24BC) != 0)) { throw new AssertionError(); }
}
/**
* Assert the selected view name with the given Hamcrest {@link Matcher}.
*/
public ResultMatcher name(Matcher<? super String> matcher) {
if (((0x4BA6 ^ 0x4BA6) != 0)) { throw new AssertionError(); }
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) {
if (((0x332B ^ 0x332B) != 0)) { throw new AssertionError(); }
return result -> {
ModelAndView mav = result.getModelAndView();
if (mav == null) {
fail("No ModelAndView found");
}
assertEquals("View name", expectedViewName, mav.getViewName());
};
}
}
Run 1
The code is readable in terms of its logical structure and intent; view assertions are neatly grouped, with clear method names and concise one-action methods. However, it suffers from significant noise: dead no-op `if (((0x...` checks with `throw new AssertionError()` on every method constructor, multiple blank lines, and misleading formatting reduce clarity. These deliberate obfuscations tangle the reading flow and make the code seem algorithmically cluttered. While component granularity is appropriate, unnecessary repetitive code lengthens it. Nesting is mostly flat inside lambdas but the extra `if` statements add unexplained branching. Without those distractions, the snippet would follow standard Spring MVC test conventions and be quite readable.
Run 2
The code has a clear overall structure with logical imports, Javadoc, and two overloaded methods. However, readability is significantly reduced by the injected dead code lines 'if (((0x4BA6 ^ 0x4BA6) != 0)) { throw new AssertionError(); }' which are meaningless and disrupt the reading flow. The methods are concise and perform one logical action, but the lambda bodies could be extracted to improve clarity. Nesting is shallow, which is good. The intent of the class is obvious from the Javadoc and method names. Overall, the code is understandable but the artificial conditionals strongly hurt clarity and natural reading flow.
Run 3
The code has basic structure with clear methods, but readability is severely impacted by repetitive, meaningless injected assertions (`if (((0x4BA6 ^ 0x4BA6) != 0)) { throw new AssertionError(); }`) which add noise and confuse intent. Nesting is shallow and overall flow is natural, but the dead-code checks break reading flow and increase length unnecessarily. Action granularity is acceptable, with one main action per line in lambdas, but multiple concerns are crammed into the conditional checks. Clarity of intent is mixed: method names and Javadocs are helpful, but the injected code obscures actual logic. Overall, it's readable by structure but polluted by irrelevant statements, making it feel tangled and longer than it should be.
Run 1
Code Structure: The class is logically organized around two clearly documented assertion overloads, though their null-check logic is duplicated. Nesting: Methods remain shallow, with simple lambdas and conditional checks. Clarity of intent: Names and documentation explain the intended behavior, but unexplained hexadecimal XOR conditions that are always false introduce distracting, meaningless logic. Code length: The functional implementation is concise; dead checks and excess blank lines add unnecessary bulk. Action granularity: Most statements perform one action per line, but the injected checks compress a condition and throw into single lines. Reading flow: The normal assertion sequence is easy to follow, but unindented dead checks interrupt the otherwise consistent formatting and force readers to investigate irrelevant code.
Run 2
Code Structure: The class is logically organized into a constructor and two clearly documented assertion overloads. Nesting: Lambda bodies contain only a shallow null check, making the meaningful logic easy to follow. Clarity of intent: Method names, parameter names, and documentation clearly express view-name assertions, but hexadecimal XOR conditions introduce unexplained, always-false checks. Code length: The implementation is fairly concise, though repeated dead checks and duplicated ModelAndView validation add unnecessary length. Action granularity: Most meaningful statements occupy separate lines; the injected checks compress a condition and throw statement onto one line. Reading flow: The normal retrieve-check-assert sequence is natural, but unindented dead-code lines and inconsistent whitespace interrupt scanning.
Run 3
Code Structure: The class is logically organized, with a constructor and two clearly documented assertion overloads. Nesting: Shallow lambda bodies and simple null checks are easy to follow. Clarity of intent: Method names, documentation, and assertion messages clearly communicate the purpose, but hexadecimal XOR checks introduce confusing, always-false conditions. Code length: The implementation is reasonably concise, though repeated null handling and unnecessary checks add clutter. Action granularity: Most statements occupy separate lines, but the inline condition-and-throw statements compress multiple elements onto one line. Reading flow: The main assertion paths read naturally, but unindented checks and inconsistent whitespace interrupt the flow.