Source code
package org.springframework.test.web.reactive.server;
import org.jspecify.annotations.Nullable;
import org.springframework.http.client.reactive.ClientHttpConnector;
import org.springframework.web.server.adapter.WebHttpHandlerBuilder;
/**
* Contract to encapsulate customizations to a {@link WebTestClient.Builder}.
* Typically used by frameworks that wish to provide a shortcut for common
* initialization.
*
* @author Rossen Stoyanchev
* @since 5.0
* @see MockServerConfigurer
*/
public interface WebTestClientConfigurer {
/**
* Use methods on {@link WebTestClient.Builder} to modify test client
* settings. For a mock WebFlux server, use {@link WebHttpHandlerBuilder}
* to customize server configuration. For a MockMvc server, mutate the
* {@link org.springframework.test.web.servlet.client.MockMvcHttpConnector}
* and set it on {@link WebTestClient.Builder}.
* @param builder the WebTestClient builder for test client changes
* @param httpHandlerBuilder for mock WebFlux server settings
* @param connector the connector in use
*/
void afterConfigurerAdded(WebTestClient.Builder builder,
@Nullable WebHttpHandlerBuilder httpHandlerBuilder,
@Nullable ClientHttpConnector connector);
}
Run 1
The code is a well-structured Spring interface with clear intent. It has minimal nesting (none), appropriate length for its purpose, and each parameter is on its own line for readability. The Javadoc provides comprehensive context about how to use the interface, including references to related classes. The package structure and imports are standard and organized. The annotation @Nullable is used consistently. The method signature is clean and logically ordered. Points deducted only because the Javadoc could be slightly more concise, and there is a minor formatting inconsistency with the parameter continuation indentation. Overall, this is exemplary interface design that follows Java conventions perfectly.
Run 2
The code demonstrates excellent readability. The package and imports are clean, with appropriate nullability annotations. Javadoc comments clearly explain the interface's purpose, parameters, and usage scenarios, making intent unambiguous. The interface is concise with a single method containing three logically grouped parameters. Indentation follows standard conventions. While the method parameters span multiple lines, this aids readability rather than hindering it. The only minor deduction is that the Javadoc could be slightly more concise, but the detailed documentation serves an educational purpose for framework users. Overall, this is well-structured, properly nested, and easy to understand code.
Run 3
The code exhibits excellent readability. Structure is clear: package declaration, imports, Javadoc, and a single interface method with a logical parameter list. Nesting is minimal, with no control-flow complexity. Intent is well-documented through concise Javadoc explaining the purpose and usage context for each parameter. The code is concise, containing only necessary elements without redundancy. Action granularity is appropriate, with each parameter on its own line for clarity. Reading flow is natural, following standard Java conventions and Spring Framework documentation patterns. Minor deductions: the Javadoc references external types that may require supplementary knowledge, and the method name 'afterConfigurerAdded' slightly obscures timing semantics without reading documentation.
Run 1
Code Structure: A well-organized interface with imports, interface documentation, and a single documented method. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive names and Javadoc clearly explain the customization contract, parameters, and supported server configurations; nullable annotations make optional inputs explicit. Code length: Concise and appropriate for a public API, with useful rather than excessive documentation. Action granularity: The single method declaration is cleanly split across lines, with no combined actions. Reading flow: Natural progression from contract overview to method details and signature. Minor formatting improvements, such as a blank line between the package declaration and imports, would improve visual separation.
Run 2
Code Structure: A single, logically organized interface with relevant imports and one method. Nesting: Minimal, with no nested control flow. Clarity of intent: Class and method documentation clearly describe customization responsibilities; descriptive parameter names and nullable annotations clarify usage. Code length: Concise, with documentation proportionate to the API's purpose. Action granularity: One declaration per statement, and the multiline method signature separates parameters cleanly. Reading flow: Natural progression from imports to interface documentation and method contract. Minor drawbacks are the missing blank line after the package declaration and a method name that conveys lifecycle timing more directly than its customization purpose.
Run 3
Code Structure: A well-organized interface with imports, contract documentation, and a single method. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive types and Javadoc clearly explain the customization contract and parameter roles; nullable annotations make optional inputs explicit. Code length: Concise, with documentation proportionate to the API's purpose. Action granularity: A single method declaration spans clearly separated parameter lines, with no combined actions. Reading flow: Natural progression from package and imports to interface documentation and method signature. Minor readability improvements include a blank line after the package declaration and a more explicit description of when afterConfigurerAdded is invoked.