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 a well-structured Java interface with clear intent and concise documentation. It has minimal nesting, as it's a single method declaration with no conditional logic. The Javadoc is thorough, explaining the purpose and parameters, which enhances readability. Each parameter is on its own line, following consistent formatting. The naming is expressive (e.g., `afterConfigurerAdded`, `httpHandlerBuilder`), and the use of `@Nullable` improves clarity about optional parameters. Overall, the code is easy to understand for developers familiar with Spring testing conventions.
Run 3
This interface is highly readable. The structure is clear and focused, with a single method and well-documented purpose. Nesting is minimal—only the package and interface declarations apply. The Javadoc explains intent precisely, including parameter semantics and use cases. Code length is concise: no unnecessary methods or verbose logic. Action granularity is straightforward, as the method signature is the only action and is laid out cleanly across lines. Reading flow is natural, moving from package to imports to interface definition and method contract. Minor deductions: the slightly unusual formatting of the method signature (line break before parameters) and reliance on external annotations for nullability, which could be made clearer with inclusion of those annotations in a reader's toolkit. Overall, this is exemplary production code.
Run 1
Code Structure: A clearly organized interface with imports, contract documentation, and a single method. Nesting: Minimal, with only the interface scope and no nested logic. Clarity of intent: Descriptive names and Javadoc clearly explain the customization hook, parameters, and server-specific usage; nullable annotations make optional inputs explicit. Code length: Concise, with documentation proportional to the API's purpose. Action granularity: One method declaration, cleanly split across lines for its parameters; no compounded actions. Reading flow: Natural progression from contract overview to method details and signature. A blank line between the package declaration and imports would slightly improve visual separation.
Run 2
Code Structure: A logically organized interface with imports, interface documentation, and a single method contract. Nesting: Minimal nesting, with no control flow. Clarity of intent: Descriptive names and useful Javadoc clearly explain the customization purpose, parameters, and server-specific usage; nullable annotations clarify optional inputs. Code length: Concise, with documentation proportionate to the API's purpose. Action granularity: The sole declaration is cleanly split across lines, with no combined actions. Reading flow: Natural top-to-bottom progression; a blank line between the package declaration and imports would slightly improve visual separation.
Run 3
Code Structure: A well-organized interface with imports, interface documentation, and one method declaration. Nesting: Minimal, with no nested logic or control flow. Clarity of intent: Descriptive names and detailed Javadoc explain the customization contract and parameter roles; nullable annotations clarify optional inputs. Code length: Concise, with documentation proportional to the API's purpose. Action granularity: Only one declaration, cleanly split across lines without combining unrelated actions. Reading flow: Natural progression from package and imports to contract documentation and method signature. Minor drawbacks are the lack of a blank line after the package declaration and the lengthy fully qualified class reference in the Javadoc.