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

[spuru9]

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]

CI report:

• 8ea2fa1 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[spuru9]

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