[FLINK-30815][tests] Migrate BatchAbstractTestBase and BatchTestBase to junit5

[TanYuxin-tyx]

What is the purpose of the change

Migrate BatchAbstractTestBase and BatchTestBase to junit5

Brief change log

• Migrate BatchAbstractTestBase and BatchTestBase to junit5

Verifying this change

This change is a test update without any test coverage.

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 documented)

[flinkbot]

CI report:

• 574cb79 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

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

[JunRuiLee]

@TanYuxin-tyx Thank you for creating this PR. IIUC, this PR is to migrate BatchTestBase and BatchAbstractTestBase and their subclasses to Junit5 to avoid hide some problems. I noticed that not all subclasses are included in the current commits, such as SortITCase and DeleteTableITCase. Could you please help to check which other subclasses are still using Junit4 and make the necessary modifications? Thank you very much.

[TanYuxin-tyx]

@JunRuiLee Thanks for joining the review. Considering that the two base classes have many table-related and Scala-related subclasses, it is indeed necessary to upgrade all the subclasses to JUnit5. However, I don't believe it is appropriate to update all the tests in this PR. Perhaps we should seek input from others to generate more ideas.

@godfreyhe could you please help take a look at this change, WDYT?

[JunRuiLee]

@TanYuxin-tyx Thanks for the explanation and I agree that migrating all the subclasses in one PR is cumbersome and unnecessary. What confuses me is that the title of this PR is "Migrate BatchAbstractTestBase and BatchTestBase to junit5", but the commits also include migration of some subclasses, although not all of them. I am curious why these subclasses were selected for migration. Could you please clarify? Also, I suggest splitting this into different commits.

[TanYuxin-tyx]

@JunRuiLee I agree that the sub subclasses migration can be in separate commits.
The reason for migrating some subclasses is that these classes have some problems in the new JUnit5 and can not run successfully. For example, TimestampITCase lacks the @Before annotation, which does not affect the JUnit4 test, but it can not run in the new JUnit5.

[TanYuxin-tyx]

I don't use a separate commit to fix TimestampITCase finally, because separating to a new commit will cause the previous commit of Migrate BatchTestBase to junit5 can not run the test successfully, which does not comply with the principle that every commit can be passed independently.

In addition, other normal subclasses migrations should use separate commits.

[godfreyhe]

Thanks for the contribution, I left one minor comment

[TanYuxin-tyx]

@godfreyhe Thanks for helping review the change. I have updated the code according to the comments.
I add 3 methods in BatchAbstractTestBase, createTempFolder, createTempFile, createFileInTempFolder. The subclasses call the appropriate method when needed.

[godfreyhe]

Thanks for the update, LGTM

[TanYuxin-tyx]

@godfreyhe @JunRuiLee Thanks for helping review the change.