Add execution, per Clement suggestion

Author: holly-cummins

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

@@ -26,7 +26,8 @@ However, some use cases didn't work. Tests using advanced JUnit 5 features like
 
 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.
 
-Over time, test-related defects were building up that couldn't be changed without a fundamental rewrite of test classloading. The Quarkus test code itself was also growing ever-more complex as it tried to work around various JUnit edge cases. Moving test instances from one classloader to another involved serializing and deserialization, which is harder to implement on newer JVM versions with tighter class security. For example, Quarkus used to use XStream as the serialization provider, but XStream no longer works with Java 17 and higher, because of reflection restrictions in the newer JVMs.
+Over time, test-related defects were building up that couldn't be changed without a fundamental rewrite of how Quarkus loads and executes tests.
+The Quarkus test code itself was also growing ever-more complex as it tried to work around various JUnit edge cases. Moving test instances from one classloader to another involved serializing and deserialization, which is harder to implement on newer JVM versions with tighter class security. For example, Quarkus used to use XStream as the serialization provider, but XStream no longer works with Java 17 and higher, because of reflection restrictions in the newer JVMs.
 
 What if, instead, Quarkus tests were simply run in the same classloader used to to load them?