[FLINK-39772][tests][JUnit5 migration] Module: flink-fs-tests by spuru9 · Pull Request #28497 · apache/flink

spuru9 · 2026-06-20T11:13:41Z

What is the purpose of the change

Migrate the remaining JUnit 4 tests in flink-fs-tests to JUnit 5 (Jupiter). After this PR the module has zero JUnit 4 imports. Part of the umbrella JUnit 4 → 5 migration.

JIRA: FLINK-39772 (sub-task of FLINK-25325)

Brief change log

Five test classes migrated (all under org.apache.flink.hdfstests):

HDFSTest — @Rule/@ClassRule TemporaryFolder → @TempDir, @Before*/@After* → @BeforeEach/@AfterEach/@BeforeAll, Assume.assumeTrue → Assumptions.assumeTrue (arg order swapped).
DistributedCacheDfsTest — dropped extends TestLogger; @ClassRule MiniClusterWithClientResource → @RegisterExtension static MiniClusterExtension; @ClassRule TemporaryFolder → @TempDir.
ContinuousFileProcessingITCase — extends AbstractTestBaseJUnit4 → extends AbstractTestBase (the JUnit 5 sibling); lifecycle annotations.
ContinuousFileProcessingTest — lifecycle annotations, @ClassRule TemporaryFolder → @TempDir (+ TempDirUtils).
ContinuousFileProcessingMigrationTest (parameterized) — @RunWith(Parameterized.class) → @ExtendWith(ParameterizedTestExtension.class) with @Parameter field injection and @TestTemplate; @SnapshotsGenerator methods kept public (the migration framework discovers them via Class#getMethods()).
Assertions converted to AssertJ; org.junit.* imports removed; public dropped from test classes/methods per the Flink JUnit 5 Migration Guide.

One assertion in testReaderSnapshotRestore keeps Collection#contains(...) (rather than AssertJ's assertThat(coll).contains(...)) on purpose: FileInputSplit#equals is asymmetric with its TimestampedFileInputSplit subclass, and AssertJ reverses the equals direction. A comment documents this.

No production code is touched.

Verifying this change

This change is a test-only migration covered by the existing tests it migrates:

./mvnw -pl flink-fs-tests test \
  -Dtest='ContinuousFileProcessingTest,ContinuousFileProcessingITCase,ContinuousFileProcessingMigrationTest,DistributedCacheDfsTest,HDFSTest'

Result: 50 tests run, 0 failures, 0 errors, 0 skipped, matching the pre-migration baseline.

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

Was generative AI tooling used to co-author this PR?

Yes — Claude Code

flinkbot · 2026-06-20T11:23:09Z

CI report:

Bot commands

The @flinkbot bot supports the following commands:

@flinkbot run azure re-run the last Azure build

spuru9 · 2026-06-20T11:32:29Z

Have used TempDir in most cases but in some multiple distinct temp dirs are needed here, so TempDirUtils.newFolder(tmpFolder) is simpler than injecting several @tempdir params. This is acceptable as per the Migration gdoc

spuru9 · 2026-06-22T13:11:23Z

cc: @raminqaf @snuyanzin Can you review this PR as well on JUnit5 migration.

snuyanzin · 2026-06-22T17:44:43Z

        monitoringFunction.run(context);

-        Assert.assertArrayEquals(filesKept.toArray(), context.getSeenFiles().toArray());
+        assertThat(context.getSeenFiles().toArray()).isEqualTo(filesKept.toArray());


why do we need conversion to array here?

Have done for 1x1 replacement so had it, also the same for isTrue and some others. Will add it my learning for the PR for other submodules.

snuyanzin · 2026-06-22T17:45:43Z

+        assertThat(initTestInstance.getOutput().contains(new StreamRecord<>(fsSplit1))).isTrue();
+        assertThat(initTestInstance.getOutput().contains(new StreamRecord<>(fsSplit2))).isTrue();
+        assertThat(initTestInstance.getOutput().contains(new StreamRecord<>(fsSplit3))).isTrue();
+        assertThat(initTestInstance.getOutput().contains(new StreamRecord<>(fsSplit4))).isTrue();


assert has contains method, so no need for isTrue

the queue holds TimestampedFileInputSplits but we assert against a plain FileInputSplit, and their equals is asymmetric. Collection#contains checks expected.equals(actual) (passes); AssertJ's .contains reverses it (fails).

snuyanzin · 2026-06-22T17:45:56Z


-        Assert.assertArrayEquals(
-                initTestInstance.getOutput().toArray(), restoredTestInstance.getOutput().toArray());
+        assertThat(restoredTestInstance.getOutput().toArray())


what is the reason to convert to array here?

snuyanzin · 2026-06-22T17:46:16Z

                cntntStr.append(line);
            }
-            Assert.assertEquals(expectedFileContents.get(fileIdx), cntntStr.toString());
+            assertThat(cntntStr.toString()).isEqualTo(expectedFileContents.get(fileIdx));


assertJ has hasToString()

snuyanzin · 2026-06-22T17:46:34Z

        // of the input stream.

-        Assert.assertEquals(NO_OF_FILES * LINES_PER_FILE + 1, tester.getOutput().size());
+        assertThat(tester.getOutput().size()).isEqualTo(NO_OF_FILES * LINES_PER_FILE + 1);


why not hasSize?

snuyanzin · 2026-06-22T17:47:19Z

+import static org.assertj.core.api.Assertions.fail;
+import static org.junit.jupiter.api.Assumptions.assumeTrue;


I'm not sure it is a good idea to mix assertj and junit5
let's use assumptions from assertj

snuyanzin · 2026-06-22T17:48:30Z

    private static int getLineNo(String line) {
        String[] tkns = line.split("\\s");
-        Assert.assertEquals(6, tkns.length);
+        assertThat(tkns.length).isEqualTo(6);


snuyanzin · 2026-06-22T17:48:55Z

        t.join();

-        Assert.assertArrayEquals(filesToBeRead.toArray(), context.getSeenFiles().toArray());
+        assertThat(context.getSeenFiles().toArray()).isEqualTo(filesToBeRead.toArray());


why do we need to transform to array?

spuru9 · 2026-06-22T19:10:51Z

Thanks @snuyanzin. I implemented 1:1 mechanical conversions from the JUnit 4 assertions, so the old shape (.size()+isEqualTo, contains(...).isTrue(), .toArray()) carried over instead of the fluent forms.
Have taken a note to add optimal form of test for the other migrations.

snuyanzin

Thanks @snuyanzin. I implemented 1:1 mechanical conversions from the JUnit 4 assertions, so the old shape (.size()+isEqualTo, contains(...).isTrue(), .toArray()) carried over instead of the fluent forms.
Have taken a note to add optimal form of test for the other migrations.

thanks for working on this, however we should not just blindly convert it with all the bugs/suboptimal code
we should clean it as well since it is pretty straightforward in order to not just move under the rug

spuru9 · 2026-06-22T19:39:46Z

Got it. Have made the changes, also took a look on the other parts if they could be optimised.

spuru9 force-pushed the feature/junit5-fs-tests branch from 621df3c to ee5bd24 Compare June 20, 2026 11:26

spuru9 marked this pull request as ready for review June 20, 2026 11:32

spuru9 force-pushed the feature/junit5-fs-tests branch from ee5bd24 to 8ea2fa1 Compare June 20, 2026 11:37

snuyanzin reviewed Jun 22, 2026

View reviewed changes

spuru9 force-pushed the feature/junit5-fs-tests branch from 8ea2fa1 to 06f1d46 Compare June 22, 2026 19:14

spuru9 requested a review from snuyanzin June 22, 2026 19:16

snuyanzin requested changes Jun 22, 2026

View reviewed changes

[FLINK-39772][tests][JUnit5 migration] Module: flink-fs-tests

e07ada4

spuru9 force-pushed the feature/junit5-fs-tests branch from 06f1d46 to e07ada4 Compare June 22, 2026 19:37

spuru9 requested a review from snuyanzin June 22, 2026 19:53

		import static org.assertj.core.api.Assertions.fail;
		import static org.junit.jupiter.api.Assumptions.assumeTrue;

Conversation

spuru9 commented Jun 20, 2026

What is the purpose of the change

Brief change log

Verifying this change

Does this pull request potentially affect one of the following parts:

Documentation

Was generative AI tooling used to co-author this PR?

Uh oh!

flinkbot commented Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

CI report:

Uh oh!

spuru9 commented Jun 20, 2026

Uh oh!

spuru9 commented Jun 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spuru9 commented Jun 22, 2026

Uh oh!

snuyanzin left a comment

Choose a reason for hiding this comment

Uh oh!

spuru9 commented Jun 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

flinkbot commented Jun 20, 2026 •

edited

Loading