Subject: [pgjdbc/pgjdbc] PR #3652: chore: update JUnit to 5.13, use @ParameterizedClass

From: "vlsi (@vlsi)" <[email-masked]>
Date: Sun, 01 Jun 2025 16:23:42 +0000

JUnit 5.13 brings @ParameterizedClass which makes it way easier to migrate JUnit 4 @Parameterized tests to JUnit 5.

Notes for the reviewers:
* I used IDEA's inspection to automatically convert JUnit4 assertions and assumptions to JUnit5
* I used IDEA's "simplify assertion" to automatically convert cases like `assertTrue(!x)` into `assertFalse(x)`
* `@ParameterizedClass` is experimental in JUnit 5.13, however, it feels so good to finally drop JUnit4 from the dependencies so we no longer have multiple `@Test` annotations

RedHat Bugzilla regarding JUnit 5.13 update: https://bugzilla.redhat.com/show_bug.cgi?id=2276648

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Sun, 01 Jun 2025 21:02:16 +0000

I was wondering how you did this. I'm curious how well an LLM would have done

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 02 Jun 2025 07:34:04 +0000

The procedure was like
* remove `import org.junit.Test;`
* autofix "import `@Test`" with junit5
* autofix "JUnit4 assertions used in JUnit5 test"
* make all Assertion imports static
* wrap long assertion lines if needed <-- this was manual
* replace `@RunWith(Parameterized.class)` with `@ParameterizedClass`, add `@MethodSource("data")`

My guess is that with an LLM I would not have any confidence in the result: JUnit4 and JUnit5 have different order of arguments for `assertEquals`, and sometimes the code was using the wrong order.

As I migrated the code I did not bother understanding the diffs as long as it compiled.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 02 Jun 2025 08:00:38 +0000

A funny finding: `AutoRollbackTestSuite` was not executed during the CI tests as the test name was wrong.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Mon, 02 Jun 2025 09:02:34 +0000

> My guess is that with an LLM I would not have any confidence in the result: JUnit4 and JUnit5 have different order of arguments for `assertEquals`, and sometimes the code was using the wrong order.
I've had pretty positive results with an LLM

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Mon, 02 Jun 2025 09:02:51 +0000

> A funny finding: `AutoRollbackTestSuite` was not executed during the CI tests as the test name was wrong.

Good catch!

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 02 Jun 2025 09:43:09 +0000

Copr build fails as it still ships with a much older junit: `Installing junit5-0:5.10.2-14`

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 02 Jun 2025 09:54:11 +0000

The following test still requires JUnit4 as classloader-leak-prevention [supports JUnit 4 only](https://github.com/mjiderhamn/classloader-leak-prevention/issues/150):

```java
@RunWith(JUnitClassloaderRunner.class)
@LeakPreventor(DriverSupportsClassUnloadingTest.LeakPreventor.class)
@PackagesLoadedOutsideClassLoader(
    packages = {"java.", "javax.", "jdk.", "com.sun.", "sun.", "org.w3c", "org.junit.", "junit.",
        "se.jiderhamn."}
)
class DriverSupportsClassUnloadingTest {
```

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 02 Jun 2025 10:47:07 +0000

I've implemented all the changes. Now all the core tests use JUnit5 only.
I've added a dependency constraint that would fail the build should JUnit4 appear as a direct or indirect dependency.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 04 Jun 2025 18:06:15 +0000

Should we wait for Fedora to integrate JUnit 5.13, or could we merge this with Copr still failing?