Skip to content

Conversation

@CodingMasterLSW
Copy link

@CodingMasterLSW CodingMasterLSW commented Jan 20, 2026

This PR migrates parameterized tests to @ParameterizedClass in the spring-core module.

To prioritize code cohesion, I actively use @Nested test classes.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 20, 2026
@sbrannen sbrannen changed the title Migrate ResourceTests to @ParameterizedClass in spring-core Migrate tests to @ParameterizedClass in spring-core Jan 20, 2026
@sbrannen sbrannen added the type: task A general task label Jan 20, 2026
@sbrannen sbrannen self-assigned this Jan 20, 2026
@sbrannen
Copy link
Member

Please provide the DCO sign-off in all commits.

Signed-off-by: CodingMasterLSW <spqjekdl1004@gmail.com>
Signed-off-by: CodingMasterLSW <spqjekdl1004@gmail.com>
@CodingMasterLSW CodingMasterLSW force-pushed the fix-parameterized-class branch from f8245c7 to 151df60 Compare January 20, 2026 15:19
@CodingMasterLSW
Copy link
Author

@sbrannen
I have updated the commits to include the DCO sign-off. Thanks for pointing that out!

Copy link
Member

@sbrannen sbrannen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the first PR in this "series"! 👍

I think we'll "learn as we go" regarding how best to achieve this migration.

So, I've requested a few changes as a first step.

Comment on lines 36 to 37
@ParameterizedClass
@MethodSource("org.springframework.core.testfixture.io.buffer.AbstractDataBufferAllocatingTests#dataBufferFactories()")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't this be declared directly on AbstractDataBufferAllocatingTests?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved these annotations to the AbstractDataBufferAllocatingTests class.

Comment on lines 40 to 42
DataBufferTestUtilsTests(DataBufferFactory bufferFactory) {
DataBufferTestUtilsTests.this.bufferFactory = bufferFactory;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, instead of declaring such constructors in each subclass, I think it would be much better to annotate the bufferFactory field in AbstractDataBufferAllocatingTests with @Parameter.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, That's great point!
I'm new to @parameter, so I appreciate you pointing that out!

@Nested
@ParameterizedClass
@MethodSource("org.springframework.core.testfixture.io.buffer.AbstractDataBufferAllocatingTests#dataBufferFactories()")
class ParameterizedDataBufferUtilsTests {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the @Nested test classes like this one should extend AbstractDataBufferAllocatingTests, and the enclosing classes should no longer extend that.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense to me.
Reflected your feedback in 672157b.

assertThatExceptionOfType(FileNotFoundException.class).isThrownBy(() -> relative4.getContentAsString(UTF_8));
}

private static Stream<Arguments> resource() throws URISyntaxException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
private static Stream<Arguments> resource() throws URISyntaxException {
private static Stream<Arguments> resources() throws URISyntaxException {

While we're at it, we might as well rename that method to "resources".

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reflected your feedback in 84d677b

private final MultiValueMap<String, String> map;

public ParameterizedMultiValueMapTests(MultiValueMap<String, String> map) {
this.map = new LinkedMultiValueMap<>(map);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
this.map = new LinkedMultiValueMap<>(map);
this.map = map;

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found a potential issue with using @ParameterizedClass in this case.

Since the parameter object from @MethodSource is created only once and shared across all test methods,
modifying it (e.g., this.map = map;) causes state to leak between tests.

To ensure test isolation, I've considered the following options:

  1. Create a defensive copy in the constructor (current approach)
    Since the constructor is called for each test method, instantiating a new object ensures each test gets its own isolated instance.

  2. Use @ParameterizedTest instead
    Each test method receives a fresh parameter instance, but this requires repeating the parameter declaration for every test method.

Please let me know if there's a better way to handle this!

…ferAllocatingTests

Signed-off-by: CodingMasterLSW <spqjekdl1004@gmail.com>
Signed-off-by: CodingMasterLSW <spqjekdl1004@gmail.com>
@CodingMasterLSW
Copy link
Author

Hi @sbrannen,

I've applied your feedback. Additionally, I’ve updated ServerSentEventHttpMessageWriterTests and WebClientDataBufferAllocatingTests (which inherit from AbstractDataBufferAllocatingTests) to use the @test annotation as well.

Also, I’ve left a comment regarding a potential issue with one of the suggested changes. I’d appreciate it if you could share your thoughts on that.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: waiting-for-triage An issue we've not yet triaged or decided on type: task A general task

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants