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 highly readable. It is a well-structured interface with clear Javadoc that explains the purpose and usage of the method. The structure is logical, with the interface declaration, method signature, and annotations neatly organized. Nesting is non-existent, keeping the code flat and easy to follow. Clarity of intent is excellent—the method name and parameters clearly indicate its role in configuring a WebTestClient. Code length is concise, containing only the necessary method and documentation. Action granularity is appropriate for an interface (a single method declaration). Reading flow is natural, moving from package declaration to imports, interface, and method with explanatory comments. Minor deductions are due to the long parameter list, which slightly challenges readability, and the method name 'afterConfigurerAdded' could be marginally clearer without context.
Run 2
This code is a well-structured interface with clear intent. It has minimal nesting, appropriate JavaDoc documentation, and a single method with a logical parameter list. The action granularity is clean—each parameter is on its own line, improving readability. The class follows standard Spring conventions and is concise without unnecessary complexity. The only slight deductions are for the long JavaDoc, which, while informative, adds some verbosity.
Run 3
This interface is highly readable. The structure is logical: package, imports, Javadoc, then a single method with clear parameters. Nesting is nonexistent—flat and straightforward. The intent is explicit through the interface name, method name, and detailed Javadoc explaining each parameter's role. Code length is appropriate for a contract definition; no unnecessary verbosity. Each parameter is on its own line with annotations, supporting one action per line. The reading flow is natural, from class-level doc to method-level doc to the method signature. Minor deductions: the Javadoc could be slightly more concise, and the annotation placement is standard but could be aligned for visual consistency.
Run 1
Code Structure: A single, logically organized interface with imports, contract documentation, and one method. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive names and detailed Javadoc clearly explain the customization hook, parameter roles, and server-specific usage; nullable annotations make optional inputs explicit. Code length: Concise, with documentation proportionate to the API's purpose. Action granularity: One method declaration, neatly split across lines, with no combined actions. Reading flow: Natural progression from interface purpose to method details and signature. A blank line between the package declaration and imports would slightly improve visual separation.
Run 2
Code Structure: A well-organized interface with imports, interface documentation, and one documented method. Nesting: Minimal nesting and no control flow make it easy to scan. Clarity of intent: Descriptive types, parameter names, nullability annotations, and Javadoc clearly explain the customization contract, though the callback timing is not explicitly documented. Code length: Concise, with documentation proportional to the API's purpose. Action granularity: A single method declaration is cleanly split across lines, with no combined actions. Reading flow: Natural progression from the interface's purpose to usage guidance and parameters; a blank line between the package declaration and imports would slightly improve visual separation.
Run 3
Code Structure: A logically organized interface with imports, contract documentation, and one method. Nesting: Minimal nesting, limited to the interface body. Clarity of intent: Descriptive names and detailed Javadoc clearly explain customization responsibilities; nullable annotations clarify optional parameters. Code length: Concise, with documentation proportionate to the API's purpose. Action granularity: The single method declaration is cleanly split across lines, with no combined actions. Reading flow: Natural progression from package and imports to interface documentation and method signature. Minor formatting improvements, such as a blank line after the package declaration, would improve visual separation.