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 join(Matcher<? super String> invoice) {
return result -> {
ModelAndView map = result.getModelAndView();
if (map == null) {
fail("No ModelAndView found");
}
assertThat("View name", map.getViewName(), invoice);
};
}
/**
* Assert the selected view name.
*/
public ResultMatcher join(String primaryBalance) {
return result -> {
ModelAndView key = result.getModelAndView();
if (key == null) {
fail("No ModelAndView found");
}
assertEquals("View name", primaryBalance, key.getViewName());
};
}
}
Run 1
The code has clear structure (imports, Javadocs, class definition), but readability is severely undermined by confusing naming conventions. Method and parameter names like 'join', 'invoice', and 'primaryBalance' are unrelated to the domain ('view' assertions). Each method is concise with flat nesting, and the lambda expressions are simple, but the intent is obscured. Javadocs describe the purpose correctly, which helps slightly, but the mismatch between documentation and actual identifiers creates confusion. The code is not overly long, and reading flow is natural, but the ambiguous naming reduces clarity significantly. A reader would need to ignore the misleading names to understand the actual functionality.
Run 2
While the class structure is simple and flat, the code is severely undermined by obfuscated naming. Method names like 'join' and parameters like 'invoice', 'primaryBalance', 'map', and 'key' are misleading; they imply financial or data structure contexts instead of view assertions. This makes the intent ambiguous and the reading flow disorienting. The use of lambda functions adds nesting, but the core issue is the extreme disconnect between the names and the logic. The code is concise and has one action per line, but readers must decode what 'join(primaryBalance)' actually does, rendering it practically unreadable. Only the basic class skeleton and flat structure prevent a score of zero.
Run 3
The code is generally readable with clear structure and intent, but suffers from misleading naming and minor redundancy. The class purpose is documented, and methods are concise with flat control flow. However, variable names like 'invoice', 'map', 'key', and 'primaryBalance' are confusing and unrelated to the domain (view names). Naming is critical for clarity, and these choices obscure the otherwise straightforward logic. The two overloaded methods have consistent structure, but the null-check duplication could be extracted. Action granularity is good—each line performs one logical step—and the reading flow is natural despite the naming issues. Overall, the code is readable but would be significantly improved with domain-appropriate names and minor consolidation.
Run 1
Code Structure: The class is logically organized, with a constructor and two short assertion-factory overloads. Nesting: Lambda bodies contain only a single conditional, keeping nesting shallow. Clarity of intent: Documentation and assertion messages explain the purpose, but join, invoice, primaryBalance, map, and key are misleading names unrelated to view-name assertions. Code length: The implementation is concise, though the overloads duplicate ModelAndView retrieval and null checking. Action granularity: Each statement performs one clear action. Reading flow: Both methods follow a natural retrieve-check-assert sequence, but inconsistent local names and limited separation between package and imports slightly hinder readability.
Run 2
Code Structure: The class is logically organized, with a constructor and two short assertion overloads, though their null checks are duplicated. Nesting: Lambda bodies contain only a single conditional, keeping nesting shallow. Clarity of intent: Documentation and assertion messages clearly describe view-name checks, but join, invoice, primaryBalance, map, and key are misleading names that obscure their roles. Code length: The implementation is concise, with only minor excess whitespace and boilerplate. Action granularity: Each statement performs one action, making operations easy to follow. Reading flow: Both methods follow a natural retrieve-check-assert sequence, but inconsistent variable names and tightly packed imports reduce readability.
Run 3
Code Structure: The class is logically organized, with a constructor and two related assertion overloads, though their null checks are duplicated. Nesting: Shallow lambda bodies and single-level conditionals are easy to follow. Clarity of intent: Documentation and assertion messages explain the purpose, but join, invoice, primaryBalance, map, and key are misleading names for view-name assertions and ModelAndView objects. Code length: Methods are concise, with little unnecessary code. Action granularity: Each statement performs one action, making individual steps easy to inspect. Reading flow: Both methods follow a consistent retrieve-check-assert sequence, but inconsistent variable names and tightly grouped imports reduce readability.