Change/reintroduce junit5

[Philzen]

This is an effort to keep Junit 5 in the stack and instead drop Junit 4.

The main issue that led to the necessity for #18786 has been fixed following the hint at https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html#How_to_run_TestNG_tests_within_the_JUnit_Platform:

This gist is: whenever importing org.junit.jupiter:junit-jupiter-api, simply import org.junit.support:testng-engine alongside it to ensure the junit engine picks up TestNG tests.

Before

https://github.com/OpenAPITools/openapi-generator/pull/18559/checks?check_run_id=25578252872

After

https://github.com/OpenAPITools/openapi-generator/pull/18790/checks?check_run_id=25577304652

… so it transpires with this setup at least junit5 @Disabled tests are included in the "skipped"-count (this matches as there is currently only a single file JetbrainsHttpClientClientCodegenTest that uses this).

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh ./bin/configs/*.yaml
  ./bin/utils/export_docs_generators.sh
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.6.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[wing328]

thanks for the PR. I tried the solution to import org.junit.support:testng-engine before but no luck. Will give it another try later with your PR later this week.

[Philzen]

Just FYI i when i reverted your commit i excluded your template update described here, so this should be a clean PR only dealing with the test stack.

BTW i also fixed the tests that were failing in secret.

[wing328]

thanks for the FYI.

fine to fix the template in another PR instead.

but here is one thing: if the template fix is not included, then the JAXRS SPEC test should fail, right? I'd a quick look at the PR and don't see any change to the JAXRS-SPEC test (java unit test)

(I didn't have time to fully review and test this change yet...)

[Philzen]

What i meant with "i excluded your fix in the revert" was: it is still there, untouched since you merged it in #18786 (that's why i didn't even realize it was fixing one of the uncovered failing tests). Oh yeah, also left your fix for KotlinWiremockServerCodegen in there.

So the only test i saw failing and had to fix after the revert commit was really SharedTypeScriptTest.

[wing328]

thanks for the fix. the build scan confirmed the previously-skipped tests are running fine in this PR: https://ge.openapi-generator.tech/s/xa7x7pf5oj6n4

manually trigger some test failures, which are correctly reported as expected.

[Philzen]

Awesome, thanks for the review and merge. I'm currently contemplating to write an OpenRewrite recipe to convert from TestNG to Junit5, so we'd have only a single test framework in the stack.

https://ge.openapi-generator.tech/s/xa7x7pf5oj6n4

That is a most interesting link that i did know of before … how does it fit into the existing CI infrastructure, is this documented anywhere so other onboarding devs can discover it too?