HSEARCH-3654 HSEARCH-4674 Upgrade to JUnit 5 + TestContainers

[marko-bekhta]

https://hibernate.atlassian.net/browse/HSEARCH-3654
https://hibernate.atlassian.net/browse/HSEARCH-4674

Made a few tiny changes here 🥲

There are a few parts to this PR:

• assertions and assumptions
• rules converted to extensions
• parameterized tests

Assertions and assumptions

• all assertions are converted to AssertJ assertThat(). As with Jupiter, the place for asserts changed and to keep things consistent, it's nice to have it all written in a similar manner.
• as it was mentioned in the forbidden API config that we shouldn't be using AssertJs assumptions - those got converted to new Jupiter ones, which obviously not only switched their package but also the order of parameters 🥲
• the same is for expected exceptions that in some tests were part of the @Test annotation - those got converted to assertThatThrownBy() blocks

Rules converted to extensions

• Even though originally things started with BeforeTestExecutionCallback, AfterTestExecutionCallback soon after, I realized that we have tests here and there that can use extensions in the before/after methods. Hence going with BeforeEachCallback/AfterEachCallback callbacks is a safer option
• 3d party extensions like @TempDir or WireMock are more or less straightforward changes.
• Mockito extension was originally using:

@Rule
public final MockitoRule mockito = MockitoJUnit.rule().strictness( Strictness.STRICT_STUBS );

where .strictness( Strictness.STRICT_STUBS ) part seems to be redundant as strict stubs are the default option in Mockito now. But nevertheless, just to keep things as they were, this got converted to @MockitoSettings(strictness = Strictness.STRICT_STUBS)

• RetryRule was an interesting case as it utilizes both TestTemplateInvocationContextProvider and TestExecutionExceptionHandler, which probably none of the other our own extensions did. TestTemplateInvocationContextProvider allows multiplying the execution of a test generating a stream of contexts.
• takari-cpsuite dependency that was used to run TCK tests within IDE is removed and replaced with a simple main method and Jupiter launcher.
• Rules that originally were used both as @ClassRule and @Rule has a Type enum in them so that just one set of callbacks is executed. They also got a corresponding "***Global()static method to create what was previously a@ClassRule`

Everything else was more or less straightforward, where the rule Statement is now split into a pair of Before/After callbacks and occasionally an exception handler.

Runners

these aren't really extensions, but there wasn't much use of them in the tests:

• a few Spring tests
  • those from the showcase library do not have the runner anymore as the @SpringTest already has the correct extension registered
  • those that we have in ORM mapper Spring ITs got the @ExtendWith(SpringExtension.class)
• @Nested got replaced with Jupiter native annotation
• a few tests that were using BytecodeEnhancerRunner are currently disabled this is our own runner coming from ORM, and from what I see, it replaces the classloader, which, as I understood, isn't possible with Jupiter yet based on my research through Jupiter tickets.

Parameterized tests

Even though these generated a lot of changes, there's not much to say about them. Parameterized tests in Jupiter are different from what they were in 4 🥲

• Those tests that we originally had parameterizing the "rules" cannot do that anymore, as the extension should already be initialized at the moment when the parameters are resolved. So instead of putting the extension as a parameter - the configs of the extension are pushed to parameters, and then the extension gets configured within the test.
• parameterized before calls aren't supported. As a result, I've removed some of those and just initialized things as a first step in the test.

Test containers integration

• Generic containers (GenericContainer, JdbcDatabaseContainer) are used instead of ES/DB-specific ones. Looking at those dependencies, it seems that it is still expected to provide an exact version that we want to use.
• <TESTCONTAINERS_RYUK_DISABLED>true</TESTCONTAINERS_RYUK_DISABLED> Ryuk container is disabled as it wasn't able to start on CI.
• Container reuse is also turned off. I've tested it locally, and all seems to work great. But because of disabled Ryuk and me being not super familiar with what's exactly happening on CI, I didn't want to make CI boxes run containers forever 😄
• Because the test container would generate a random port, there were a few places that caused "problems" setting the values that we need. In those cases, the values are set with System.setProperty(). I've run into a few cases where properties could get cached or overridden by ORM 🥲
• Initially, I wanted to clean up more of maven properties and remove the groovy script, which didn't work out that great on CI 😄

[hibernate-github-bot]

Thanks for your pull request!

This pull request appears to follow the contribution rules.

› This message was automatically generated.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
31 Code Smells

No Coverage information
0.0% Duplication

[yrodiere]

Just a message to confirm I've seen that, but there's no way I can review it before the Christmas shutdown, so I'll probably only have a look next year :)

[yrodiere]

@marko-bekhta please let me know when we can close this.

I suppose we want to keep the testcontainers part around until we decide whether we want to go this way or with Dockerfiles instead (see https://hibernate.atlassian.net/browse/HSEARCH-4674?focusedCommentId=113129). But I'm not sure it's worth rebasing before we make that decision.

[marko-bekhta]

we have a new draft now #3796 😃 🙈 so let's close this one