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 through clean interface design and well-structured documentation. The package declaration and imports are logically organized. The interface has a single, focused method with clear parameters. The Javadoc is thorough and explains usage context effectively. Nesting is minimal - there's no deep indentation or complex control flow. The method signature spans multiple lines but in a conventional, readable pattern. Parameter names are descriptive and self-documenting. The use of @Nullable annotations explicitly communicates null-handling expectations. The documentation references related classes and provides implementation guidance, showing clear intent. Code length is concise - no unnecessary methods or boilerplate. The overall structure follows Spring Framework conventions perfectly, making it immediately recognizable to experienced developers. Minor deductions for the slightly verbose parameter alignment that could be slightly more compact, but this is a standard Java convention. Reading flow is natural: package->import->interface->documentation->method declaration, following logical progression from general to specific.
Run 3
The code is highly readable. It is well-structured, with a clear package declaration, focused imports, and a single-purpose interface. The Javadoc is thorough and explains the intent and usage context effectively. Nesting is minimal, and the method signature is clear despite three parameters. The code is concise, with no unnecessary complexity, and each element (annotations, parameters) is placed on its own line, enhancing clarity. The reading flow is natural: from package to imports, then to the interface contract and its documentation. Minor room for improvement includes the slightly dense Javadoc, but overall it is exemplary for an API contract definition.
Run 1
Code Structure: A single, focused interface with logically ordered imports, documentation, and method declaration. Nesting: Minimal nesting and no control flow. Clarity of intent: Descriptive names and thorough Javadoc explain the customization contract, parameters, 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, with parameters cleanly split across lines and no combined actions. Reading flow: Natural progression from interface purpose to method details and signature. Minor formatting improvements, such as a blank line after the package declaration, would improve visual separation.
Run 2
Code Structure: A single-purpose interface is logically organized with imports, documentation, and one method. Nesting: Minimal nesting makes it easy to scan. Clarity of intent: Descriptive names, Javadoc, parameter descriptions, and explicit nullability clearly communicate the customization contract. Code length: Concise, with documentation that adds useful context rather than unnecessary bulk. Action granularity: The sole method declaration is cleanly formatted, with parameters separated across lines and no combined actions. Reading flow: Natural progression from interface purpose to method usage and signature. Minor formatting improvements, such as a blank line between the package declaration and imports, would improve visual separation.
Run 3
Code Structure: A logically organized interface with imports, documentation, and a single method. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive names and thorough Javadoc explain the customization contract and parameters; nullable annotations clarify optional inputs. Code length: Concise, with documentation proportionate to the API's purpose. Action granularity: The single declaration is cleanly split across lines, without multiple actions per line. Reading flow: Natural progression from interface purpose to method details and signature. Minor formatting improvements, such as a blank line between the package declaration and imports, would improve visual separation.