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 is an interface with a single, well-documented method, making it highly readable. Structure is logical: package, imports, Javadocs, and method signature. Nesting is non-existent (flat). Intent is crystal clear—a contract for customizing WebTestClient.Builder. Code length is concise and appropriate. Action granularity is fine; the single method call has three parameters, which is acceptable. Reading flow is natural: class-level Javadoc explains purpose, method Javadoc details parameters. Minor deduction for slightly dense Javadoc and multi-line parameter alignment, but overall excellent readability.
Run 3
The code is a well-structured Spring interface with clear Javadoc documentation. Organization is logical, with the package declaration followed by imports and a single interface definition. Nesting is minimal—only one method exists within the interface. Intent is clearly conveyed through descriptive naming and comprehensive documentation. Length is appropriate for an API contract; no unnecessary code exists. Action granularity is clean, with each parameter on its own line for readability. Reading flow is natural, following standard Java conventions for interface declarations and annotations. Minor deductions: the Javadoc could be slightly more concise, and nullable annotations could potentially be consolidated, but these are negligible.
Run 1
Code Structure: A logically organized interface with imports, interface documentation, and one documented method. Nesting: Minimal nesting, limited to the interface body. Clarity of intent: Descriptive names and Javadoc clearly explain the customization contract, parameter roles, and server-specific usage; nullable annotations make optional parameters explicit. Code length: Concise, with documentation proportionate to the API's purpose. Action granularity: One method declaration with parameters split cleanly across lines; no combined actions. Reading flow: Natural top-to-bottom progression from contract overview to method details. Minor formatting improvements, such as blank lines separating the package and imports, would improve visual readability.
Run 2
Code Structure: A logically organized interface with imports, interface documentation, and one method contract. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive types, parameter names, nullability annotations, and Javadoc clearly explain the customization purpose and server-specific options. Code length: Concise; documentation adds useful context rather than unnecessary bulk. Action granularity: One declaration, with parameters split across lines for readability; no compound actions. Reading flow: Natural progression from interface purpose to method behavior and signature. Minor formatting issues, such as missing blank lines after the package declaration and before Javadoc parameter tags, slightly reduce visual separation.
Run 3
Code Structure: A single, focused interface with logically ordered imports and documentation. Nesting: Minimal nesting, limited to the interface body. 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, with documentation proportionate to the API's purpose. Action granularity: One method declaration, with parameters split across lines for readability and no combined actions. 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.