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))) {} else {
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))) {} else {
fail("No ModelAndView found");
}
assertEquals("View name", expectedViewName, mav.getViewName());
};
}
}
Run 1
The code is structured clearly with logical method separation and useful documentation, but several readability issues reduce the score. The null-check logic is particularly problematic: `if (!((mav == null))) {} else { fail(...) }` is convoluted and should simply be `if (mav == null) { fail(...) }`. This creates unnecessary branching complexity and confuses the reader. The double negation and empty if-block violate the principles of clear intent and natural reading flow. Nesting depth is acceptable, and each action generally occupies its own line. However, the duplicate null-check logic in both overloaded methods could be extracted to improve maintainability. The lambda expressions are concise but could benefit from clearer variable naming. Overall, the code is understandable to experienced developers but contains awkward constructions that could easily be simplified for improved readability.
Run 2
The code has a clear package structure and Javadoc comments, but several issues hurt readability. The null checks use a convoluted pattern: `if (!((mav == null))) {} else { fail(...) }`, which is confusing and should be a simple `if (mav == null) fail(...)`. This pattern is repeated in both methods, suggesting copy-paste without refinement. The code also mixes Hamcrest and custom assertion methods without clear rationale. Lambda expressions are concise but the null-check logic disrupts the natural reading flow. Action granularity is mostly one action per line, but the bizarre null-check structure adds unnecessary complexity. While the class is short and focused, the nesting and conditional logic are unnecessarily tangled, making the intent harder to grasp than it should be.
Run 3
The code has a clear structure and purpose, with good use of Javadoc comments and factory method patterns. However, the readability is significantly hampered by the awkward null-check condition: `if (!((mav == null))) {} else { fail(...) }`. This inverted, double-negative logic with an empty if-block is confusing and could be replaced with a straightforward `if (mav == null) { fail(...) }`. The duplication between the two `name` methods could be reduced, though it is acceptable for clarity. The code is concise, uses flat nesting, and maintains one action per line in most places, but the null-check issue disrupts natural reading flow and intent. Overall, it is readable but hindered by a few avoidable logic quirks.
Run 1
Code Structure: The class is logically organized with two clearly documented overloads, though the null-check logic is duplicated. Nesting: Shallow lambda and conditional nesting keeps complexity low. Clarity of intent: Names, documentation, and assertion messages clearly communicate the purpose, but the negated null checks with empty branches obscure a straightforward failure condition. Code length: Generally concise, with unnecessary parentheses and empty branches adding clutter. Action granularity: Each meaningful statement performs one action, although placing an empty branch and else on one line reduces clarity. Reading flow: Both methods follow a natural retrieve-check-assert sequence, but the inverted condition interrupts that flow. Replacing each conditional with if (mav == null) { fail(...); } would improve readability.
Run 2
Code Structure: The class is logically organized, with two clearly documented overloads, although their null-check logic is duplicated. Nesting: Shallow lambda and conditional nesting makes the code easy to navigate. Clarity of intent: Method names, parameter names, and documentation communicate the assertion purpose, but the negated, over-parenthesized null check and empty true branch obscure a straightforward guard. Code length: Generally concise, with minor unnecessary parentheses, empty branches, and whitespace. Action granularity: Statements perform one action each, though placing an empty branch and else on one line hurts visual clarity. Reading flow: Imports, documentation, and methods follow a natural order, but the unusual condition interrupts otherwise straightforward reading. Using if (mav == null) followed by fail would improve readability.
Run 3
Code Structure: The class is logically organized, with a documented constructor and two closely related assertion overloads, though their null checks are duplicated. Nesting: Methods remain shallow, with only a lambda and a conditional. Clarity of intent: Documentation, method signatures, and assertion messages make the purpose clear, but the negated, over-parenthesized null comparison and empty if branch obscure a simple failure check. Code length: Mostly concise; the awkward if/else structure and extra blank lines add unnecessary noise. Action granularity: Statements generally perform one action each, although the empty conditional branch is compressed onto the condition line. Reading flow: Both methods follow a predictable retrieve-check-assert sequence, but the inverted null checks interrupt otherwise natural reading.