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 nam(Matcher<? super String> mat) {
return result -> {
ModelAndView mav = result.getModelAndView();
if (mav == null) {
fail("No ModelAndView found");
}
assertThat("View name", mav.getViewName(), mat);
};
}
/**
* Assert the selected view name.
*/
public ResultMatcher nam(String expected) {
return result -> {
ModelAndView mav = result.getModelAndView();
if (mav == null) {
fail("No ModelAndView found");
}
assertEquals("View name", expected, mav.getViewName());
};
}
}
Run 1
The code is generally well-structured with clear intent and good organization. It follows standard Java conventions and has clean separation of concerns through separate methods for different assertion types. The nesting is minimal with only one level of lambda expression depth. However, there are some readability issues: the method names 'nam' are likely typographical errors (should be 'name'), which creates ambiguity and reduces clarity of intent. The duplicate null-check logic between the two methods could be extracted to reduce redundancy. The code is appropriately concise but could benefit from better method naming. Reading flow is natural with logical progression from constructor through assertion methods. Action granularity is reasonable, with each assertion on its own line within the lambdas. Overall, the code is readable but the naming issue and slight duplication prevent it from scoring higher.
Run 2
The code is highly readable. It has a clear, logical structure with a focused class, appropriate Javadoc, and a simple constructor. Nesting is minimal and flat, with only a single level inside lambdas. Intent is unambiguous: each method creates a view name matcher. Code length is appropriate—no unnecessary verbosity or duplication, though a private helper could consolidate the null-check logic. Each lambda body contains one primary action per line, enhancing clarity. The reading flow is natural: imports, class docs, constructor, then methods. Minor deductions: method names are abbreviated (`nam` instead of `name`), and the repeated null-check could be extracted, but these do not significantly impair readability.
Run 3
The code is highly readable due to its clear structure, minimal nesting, and concise implementation. Each method returns a single lambda expression that performs one logical action per line, ensuring flat control flow. The class has a clear purpose as a factory for view assertions, with Javadoc explaining usage. Method names reflect intent, and duplication between overloads is reasonable given the different matcher types. The null check adds minor nesting but remains simple and explicit. Overall, the code follows a natural reading flow, making it easy to understand and maintain.
Run 1
Code Structure: The class is logically organized, with a constructor and two related assertion overloads; minor duplication exists in ModelAndView retrieval and validation. Nesting: Shallow lambda and conditional nesting makes control flow easy to follow. Clarity of intent: Javadoc, assertion messages, and framework types clearly communicate the purpose, but abbreviated names nam, mat, and mav reduce clarity, especially the public method name nam. Code length: Short and focused, with little unnecessary code. Action granularity: Each statement performs one distinct action. Reading flow: Both methods follow a natural retrieve-validate-assert sequence, though missing spacing between package and imports and an extra blank line slightly weaken formatting.
Run 2
Code Structure: The class is logically organized with a constructor and two related assertion overloads, though their null-check logic is duplicated. Nesting: Shallow lambda bodies with a single conditional are easy to follow. Clarity of intent: Javadoc and assertion messages clearly explain the purpose, but abbreviated names such as nam, mat, and mav reduce clarity, especially the public method name nam. Code length: The implementation is concise, with only minor repetition and excess blank lines. Action granularity: Each statement performs one clear action, without compressed multi-action lines. Reading flow: Both methods follow a natural retrieve-check-assert sequence, and their parallel structure makes comparison easy. Import grouping and more descriptive identifiers would improve readability.
Run 3
Code Structure: The class is logically organized, with a constructor and two related assertion overloads; minor duplication exists in ModelAndView retrieval and null checking. Nesting: Shallow lambda bodies contain only a single conditional, making control flow easy to follow. Clarity of intent: Javadocs and assertion messages clearly explain the purpose, but abbreviated names such as nam and mat reduce clarity; mav is also less descriptive than modelAndView. Code length: Compact and proportionate to the functionality, though some repeated logic and excess blank lines could be reduced. Action granularity: Each statement performs one clear action, without compressed or compound operations. Reading flow: Both methods follow the same natural sequence—retrieve, validate, assert—making them predictable and readable. Import grouping could be improved with spacing.