Testing: allow bytecode transformations in QuarkusComponentTest #35473
Conversation
quarkus-bot
bot
added
area/arc
|
This seems to work, but is a little crazy, so I'm accepting all kinds of objections and civil disobedience :-) I also need to check this a bit more with continuous testing. |
|
Also, I have a similar change for I hope @holly-cummins can figure out a better solution, or I'll have to experiment with class loader hiearchies myself, and noone wants that 😆 |
This comment has been minimized.
This comment has been minimized.
|
Ah interesting, I didn't know we have a test for continuous testing :-) I'll look. |
This commit refactors `QuarkusComponentTestExtension` to do the same class loader dance `QuarkusTestExtension` does. The test instance is created in a new, per-test class loader, and all test method invocations are forwarded to it. The new class loader is dropped at the end of the test. A stack of test instances is maintained to support `@Nested` tests. Supporting programmatically or declaratively defined config properties, programmatically configured mocks or "simplified" interceptor methods required inventing rather creative protocols for exchanging information between the two class loaders: 1. For configuration, the map of config properties and the ordinal are passed from the original CL to the extra CL verbatim, because those are basic Java types that never exist in the extra CL. 2. For mocks, the mock creation functions are registered in both CLs under deterministic keys, so registration in one CL always matches registration in the other CL. 3. For interceptor methods, we collect all the necessary information in the original CL as a data structure composed solely from basic Java types, transfer that to the extra CL, and finish registration there.
Ladicek
force-pushed
the
component-test-bytecode-transformations
branch
from
3ac0ec3
to
7aee040
Compare
|
Fixed the continuous testing scenario. That actually allowed some simplification of the component test extension -- since the ArC-generated classes only need to be loaded by the extra CL, there's no need to distinguish between continuous testing and regular testing when generating the classes. |
Failing Jobs - Building 7aee040| Status | Name | Step | Failures | Logs | Raw logs | Build scan | Full information is available in the Build summary check run. Failures⚙️ Maven Tests - JDK 11 Windows #📦 integration-tests/maven✖ ✖ |
This commit refactors
QuarkusComponentTestExtensionto do the same class loader danceQuarkusTestExtensiondoes. The test instance is created in a new, per-test class loader, and all test method invocations are forwarded to it. The new class loader is dropped at the end of the test.A stack of test instances is maintained to support
@Nestedtests.Supporting programmatically or declaratively defined config properties, programmatically configured mocks or "simplified" interceptor methods required inventing rather creative protocols for exchanging information between the two class loaders:
Fixes #34926