Add JUnit version, per Clement suggestion

Author: holly-cummins

_posts/2025-04-22-test-classloading-rewrite.adoc

@@ -22,7 +22,7 @@ In previous versions, Quarkus tests were invoked using the default JUnit classlo
 
 This mostly worked very well, and meant that `QuarkusTest` tests mostly behaved as if they were part of the same application as the code under test.
 The Quarkus test framework could start and stop Quarkus instances at the right point in the test lifecycle, inject CDI dependencies, and do other useful Quarkus bytecode manipulation.
-However, some use cases didn't work. Tests using advanced JUnit features like `@TestTemplate` and `@ParameterizedTest` sometimes found that the same test code might appear to run in several classloaders in a single test, or that injected dependencies weren't always available.
+However, some use cases didn't work. Tests using advanced JUnit 5 features like `@TestTemplate` and `@ParameterizedTest` sometimes found that the same test code might appear to run in several classloaders in a single test, or that injected dependencies weren't always available.
 
 While Quarkus extensions can do all sorts of marvellous bytecode manipulation to improve the developer experience, they cannot manipulate test classes with the same freedom that they do normal application classes.
 
@@ -41,10 +41,15 @@ In practice, there have been a few hiccups and we've also discovered some edge c
 
 === Known regressions
 
-- *Dev services now start in the JUnit discovery phase*. Quarkus Dev Services are currently started during https://quarkus.io/guides/reaugmentation#what-is-augmentation[the augmentation phase], along with bytecode manipulation and other application initialization steps. With the new testing design, all augmentation happens at the beginning of the test run, during the JUnit discovery phase. This means all Dev Services also start at the beginning of the test run. If several test classes with different Dev Service configuration are augmented before any tests are run, multiple differently-configured Dev Services may be running at the same time. This can cause port conflicts and cross-talk on configuration values. We're hoping to have a https://github.com/quarkusio/quarkus/issues/45785[fix] for this in the next release. As a workaround, splitting conflicting tests into separate projects should fix symptoms.
+- *Dev services now start in the JUnit discovery phase*. https://quarkus.io/guides/dev-services[Quarkus Dev Services] are currently started during https://quarkus.io/guides/reaugmentation#what-is-augmentation[the augmentation phase], along with bytecode manipulation and other application initialization steps. With the new testing design, all augmentation happens at the beginning of the test run, during the JUnit discovery phase. This means all Dev Services also start at the beginning of the test run. If several test classes with different Dev Service configuration are augmented before any tests are run, multiple differently-configured Dev Services may be running at the same time. This can cause port conflicts and cross-talk on configuration values. We're hoping to have a https://github.com/quarkusio/quarkus/issues/45785[fix] for this in the next release. As a workaround, splitting conflicting tests into separate projects should fix symptoms.
+
+NOTE: What is augmentation? Augmentation is a phase of the Quarkus application build process during which the byte code of the application is optimized.
+Initialization steps that used to happen when an EAR file was deployed on a Jakarta EE server such as parsing static configuration, creating proxy instances, etc. now happen at augmentation time.
+
 - *Config access from JUnit conditions*. Using a `ConfigProvider` from a custom JUnit condition will https://github.com/quarkusio/quarkus/issues/47081[trigger a `ServiceConfigurationError`]. The workaround is to set the thread context classloader to `this.getClass().getClassLoader()` before reading config, and then set it back afterwards.
 - Increased memory footprint running tests. For suites using multiple profiles and resources, more heap or metaspace may be needed.
 
+
 === Things to watch out for
 
 - *Test order change*. As part of the rewrite, the execution order of some tests has swapped around. Of course, we all know tests should not depend on execution order if they don't set an order explicitly. However, it's easy to not notice that a test requires a certain order... until the order changes. We discovered some tests in our own suite that were sensitive to the execution order, and other people may make similar discoveries.
@@ -55,6 +60,7 @@ In practice, there have been a few hiccups and we've also discovered some edge c
 - *`@TestProfile` on `@Nested` tests.* Mixing different test profiles and test resources on `@Nested` tests is no longer supported. By definition, every `@TestProfile` must get its own Quarkus application and classloader. Having multiple classloaders execute one test isn't compatible with loading the test with the classloader used to run it.
 - *Version 2.x of the Maven Surefire plugin*. Versions below 3.x of the Maven Surefire plugin will no longer work with `@QuarkusTest`. Version 3 of the Surefire plugin was released in 2023, so version 2 is now rather old.
 
+
 == Next steps
 
 The main work of the test classloading rewrite has been delivered in 3.22, and has unlocked a bunch of possible improvements.