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 a(Matcher<? super String> a) {
return result -> {
ModelAndView b = result.getModelAndView();
if (b == null) {
fail("No ModelAndView found");
}
assertThat("View name", b.getViewName(), a);
};
}
/**
* Assert the selected view name.
*/
public ResultMatcher a(String c) {
return result -> {
ModelAndView d = result.getModelAndView();
if (d == null) {
fail("No ModelAndView found");
}
assertEquals("View name", c, d.getViewName());
};
}
}
Run 1
This code exhibits extremely poor readability due to meaningless naming (a, b, c, d, a()), which obscures the intent of both methods and variables. The code structure is somewhat modular, but the obfuscated identifiers negate any structural clarity. Nesting is shallow, which is good, but the action granularity is inconsistent—mixing null checks and assertions across multiple lines without clear grouping. The reading flow is disorganized because method names and parameters provide no semantic cues, forcing readers to parse comments and infer behavior. While the code is concise and avoids unnecessary length, the deliberate or accidental use of cryptic names makes it effectively unreadable. Clarity of intent suffers severely; only the comments and method signatures hint at the purpose. Overall, the code fails to communicate its logic efficiently, making maintenance and review unnecessarily challenging.
Run 2
The code has several significant readability issues. Method and variable names are meaningless: 'a' is used for both a Matcher parameter and a method name, 'b' and 'd' for ModelAndView, and 'c' for a String. This completely obscures the intent, despite the Javadoc explaining what the methods should do. The structure is otherwise logical and flat, with simple one-action-per-line statements, but the naming destroys clarity of intent and reading flow. The protected constructor with a comment is acceptable. The use of Hamcrest matchers and assertions is standard. However, the cryptic naming alone drops the score dramatically. The code length is concise, and nesting is minimal, but these positive aspects are nullified by the ambiguous identifiers.
Run 3
The code is structurally organized with clear package, imports, and documentation, but method and variable names are deliberately obfuscated ('a', 'b', 'c', 'd'), making the intent ambiguous. Nesting is low, with simple lambda bodies and no deep control flow. Code length is concise but at the cost of clarity. Action granularity is mostly one action per line, though some lines combine assertion calls with multiple arguments. Reading flow is natural at the class level but becomes confusing inside methods due to meaningless parameter names. The use of Hamcrest and Spring test utilities is appropriate, but the overall readability suffers primarily from poor naming choices that obscure purpose despite otherwise clean formatting.
Run 1
Code Structure: The class is logically organized into a constructor and two closely related assertion overloads. Nesting: Lambda bodies contain only one shallow conditional, making control flow easy to follow. Clarity of intent: Javadoc, assertion messages, and framework calls explain the purpose, but method name 'a' and variables 'a', 'b', 'c', and 'd' obscure meaning and distinguish the overloads poorly. Code length: The implementation is concise, with minor duplication of ModelAndView retrieval and null checking. Action granularity: Each statement performs a single clear action. Reading flow: Both methods follow the same natural retrieve-check-assert sequence, though compressed import formatting, extra blank lines, and cryptic identifiers reduce readability.
Run 2
Code Structure: The class is logically organized into a constructor and two related assertion overloads. Nesting: Lambda bodies contain only a single shallow conditional, keeping complexity low. Clarity of intent: Javadoc, assertion messages, and framework types explain the purpose, but method name 'a' and variables 'a', 'b', 'c', and 'd' obscure meaning and distinguishability. Code length: The implementation is concise; duplicated null checks are minor and reasonable for two short methods. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: Both methods follow a natural retrieve-check-assert sequence, although missing spacing around import groups and arbitrary identifiers reduce scanability.
Run 3
Code Structure: The class is logically organized, with a constructor and two related assertion overloads. Nesting: Lambda bodies contain only a single conditional, keeping nesting shallow. Clarity of intent: Javadoc, assertion messages, and framework calls explain the purpose, but method name 'a' and variables 'a', 'b', 'c', and 'd' obscure meaning significantly. Code length: The implementation is concise; duplicated null checks are minor and understandable. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: Both methods follow a natural retrieve-check-assert sequence, though poor naming and limited separation around imports reduce readability.