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
This interface is highly readable. It has a clear, logical structure with an appropriate package declaration, one import, and a well-documented purpose via Javadoc. Nesting is non-existent, keeping the code flat. The intent is unambiguous: define a contract for customizing a WebTestClient.Builder. The code is concise, with no unnecessary methods or fields. Action granularity is irrelevant here as it is an interface definition, but the method signature is clearly laid out across multiple lines for readability. The reading flow is natural, guided by detailed Javadoc comments that explain the parameters and their purposes. Overall, it follows clean interface design patterns and maintains excellent documentation.
Run 3
The code is highly readable. It has a clean, logical structure with a single interface and well-organized imports. Nesting is minimal—only one method declaration with three clearly separated parameters. The intent is explicit through comprehensive Javadoc explaining purpose, parameters, and usage context. Code length is appropriate for a configuration contract; no unnecessary verbosity. Action granularity is one logical action per line (method signature, parameters alignment). Reading flow is natural: package declaration, imports, Javadoc overview, interface definition, method with descriptive documentation. The only minor deductions are the slightly long Javadoc (still justified for clarity) and parameter wrapping across lines, but both are standard Java practices and do not impede readability.
Run 1
Code Structure: A logically organized interface with imports, interface documentation, and one documented method. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive names and Javadoc clearly explain the customization contract and each parameter; nullable annotations make optional inputs explicit. Code length: Concise and appropriate for a single-method interface, with useful rather than redundant documentation. Action granularity: One declaration, with parameters split across lines for readability; no combined actions. Reading flow: Natural progression from the interface's purpose to the method's usage and signature. Minor formatting improvements, such as separating the package declaration from imports with a blank line, would make it slightly easier to scan.
Run 2
Code Structure: A single, well-organized interface with imports, documentation, and one method. Nesting: Minimal, with no nested logic. Clarity of intent: Descriptive names, detailed Javadoc, and explicit nullability annotations clearly communicate the customization contract and parameter roles. Code length: Concise; documentation adds useful context rather than unnecessary verbosity. Action granularity: The method declaration and parameters are cleanly separated, with no combined actions. Reading flow: Natural progression from interface purpose to method usage and signature. Minor spacing improvements, such as blank lines after the package declaration and between import groups, would improve visual separation.
Run 3
Code Structure: A logically organized interface with a single, well-documented method and relevant imports. Nesting: No nested control flow; only the interface scope. Clarity of intent: Descriptive names, Javadoc, and nullable annotations clearly explain the customization contract and parameter roles. Code length: Concise, with documentation proportionate to the API's purpose. Action granularity: The single method declaration is cleanly split across lines, with one parameter per continuation line. Reading flow: Natural progression from package and imports to interface documentation and method contract. Minor formatting improvements, such as a blank line after the package declaration, would improve visual separation.