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 after(WebTestClient.Builder bui,
@Nullable WebHttpHandlerBuilder http2,
@Nullable ClientHttpConnector con);
}
Run 1
The code is a well-structured interface with clear intent, concise length, flat nesting, and good reading flow. Javadoc comments provide useful context for implementors. However, parameter names like 'bui', 'http2', and 'con' are overly abbreviated, reducing clarity. 'http2' is especially misleading as it suggests HTTP/2 rather than an HTTP handler builder, and 'bui' is a confusing truncation of 'builder'. These naming choices slightly undermine readability despite the solid structure.
Run 2
The code is highly readable. It has a clear structure with a single interface and well-organized Javadoc comments. Nesting is minimal—only one method signature. The intent is explicit: define a contract for customizing WebTestClient.Builder. The code is concise and not unnecessarily long. Action granularity is appropriate; each element (package, imports, interface, method) is on its own logical line. Reading flow is natural, moving from package declaration to imports to the interface and its method. Minor deductions include slightly awkward parameter names ('bui', 'http2', 'con') that could be more descriptive, and the method signature wraps across lines in a way that slightly disrupts visual flow.
Run 3
The code is generally readable but has some issues. The interface has a clear purpose and good Javadoc documentation, but the parameter naming is poor: 'bui', 'http2', and 'con' are overly abbreviated and ambiguous, hurting clarity of intent. The method signature spans multiple lines with inconsistent indentation, disrupting reading flow. The documentation mixes implementation details across three different concerns (builder, handler, connector), making the contract harder to understand. Action granularity is fine since it's just an interface declaration, and nesting is non-existent. The code length is concise. Overall structure is logical, but the parameter names and formatting inconsistencies prevent higher readability.
Run 1
Code Structure: A well-organized interface with imports, interface documentation, and one method. Nesting: No nested logic; the declaration is easy to scan. Clarity of intent: Javadoc clearly describes the customization contract, and nullable annotations clarify parameter expectations. However, abbreviated names (bui, http2, con) obscure meaning, and the @param names do not match the actual parameters. The method name after also leaves its lifecycle context implicit. Code length: Concise, with documentation proportionate to the API. Action granularity: Each declaration is separate, and parameters are split across lines for readability; there are no compound actions. Reading flow: Natural top-to-bottom progression, slightly weakened by the missing blank line between the package declaration and imports and the documentation/signature mismatch.
Run 2
Code Structure: A logically organized interface with imports, class documentation, and a single method. Nesting: Minimal nesting makes it easy to scan. Clarity of intent: The documentation clearly describes the customization contract, but abbreviated parameter names (bui, http2, con) obscure meaning and do not match the @param names (builder, httpHandlerBuilder, connector). The method name after is also vague without its documentation. Code length: Concise, with useful rather than excessive documentation. Action granularity: The declaration is cleanly split across lines, with no bundled operations. Reading flow: Natural top-to-bottom organization, though the documentation-to-signature naming mismatch interrupts comprehension.
Run 3
Code Structure: A logically organized interface with imports, documentation, and one method. Nesting: Minimal nesting makes it easy to scan. Clarity of intent: Javadoc clearly describes customization responsibilities, but the method name 'after' is vague, and abbreviated parameters 'bui', 'http2', and 'con' obscure their roles. The @param names also mismatch the actual parameters, reducing documentation reliability. Code length: Concise and appropriate for a small contract, with useful documentation. Action granularity: The single declaration and separately listed parameters are easy to distinguish; there are no bundled operations. Reading flow: Natural top-to-bottom organization, though missing spacing after the package declaration and inconsistent documentation names slightly interrupt readability.