Add ability to run tests with different config profiles #9933
Conversation
boring-cyborg
bot
added
area/core
area/devtools
stuartwdouglas
force-pushed
the
test-profiles
branch
from
0501a5d to
8a18bad
Compare
| */ | ||
| @Retention(RetentionPolicy.RUNTIME) | ||
| @Target(ElementType.TYPE) | ||
| public @interface WithProfile { |
There was a problem hiding this comment.
Perhaps this should be called TestProfile?
| * will have different configuration options to other tests. | ||
| * | ||
| */ | ||
| public interface QuarkusTestProfile { |
There was a problem hiding this comment.
I love the idea of having all per-test configuration under one class, really simplifies things both for users and for us :)
stuartwdouglas
force-pushed
the
test-profiles
branch
from
8a18bad to
a2ff59a
Compare
stuartwdouglas
force-pushed
the
test-profiles
branch
from
a2ff59a to
f0eabb0
Compare
stuartwdouglas
force-pushed
the
test-profiles
branch
from
f0eabb0 to
2f7b40c
Compare
|
@geoand maybe this should be @QuarkusTest(profile=MyProfile.class) rather than a separate annotation? |
|
Actually I guess that would interfere with non-annotation based use of the extension. |
|
I'll look into not having to re-augment the application when the same test profile is re-encountered after a different one was found. |
|
I am actually looking into it now, I just wanted to get the base feature in first. |
|
Oh OK :) That's exactly why I didn't start looking into it as well, I wanted to have the base part in first. If foe whatever reason you don't get around to it today, let me know and I'll pick it up. |
|
I don't think this is directly possible at the moment, as we can't re-run the static init steps. |
|
:( |
|
Actually I can probably just re-use the same bytecode but stick it in a new ClassLoader. |
| QuarkusTestProfile profileInstance = profile.newInstance(); | ||
| Map<String, String> additional = new HashMap<>(profileInstance.getConfigOverrides()); | ||
| if (!profileInstance.getEnabledAlternatives().isEmpty()) { | ||
| additional.put("quarkus.arc.selected-alternatives", profileInstance.getEnabledAlternatives().stream() |
There was a problem hiding this comment.
FYI there is also quarkus.arc.exclude-types that allows you to exclude types from discovery, i.e. ignore the specified types. And it hase the same syntax as selected alternatives: https://github.com/quarkusio/quarkus/blob/master/extensions/arc/deployment/src/main/java/io/quarkus/arc/deployment/ArcConfig.java#L99-L113
| */ | ||
| @Retention(RetentionPolicy.RUNTIME) | ||
| @Target(ElementType.TYPE) | ||
| public @interface TestProfile { |
There was a problem hiding this comment.
IMHO it would make sense to define this interface as @Inherited in case someone wants to define it on a common superclass.
For JUnit 5 tests I am also used to be able to define my own composed annotations with meta-annotations, which I think could also be very useful for Quarkus' test annotations like @QuarkusTestResource and @TestProfile. But for this I will file a separate enhancement request.
There was a problem hiding this comment.
Please do, that sounds useful
There was a problem hiding this comment.
Should I file a separate enhancement request for declaring @QuarkusTestResource and @TestProfile as @Inherited?
I don't know if 'profile' is the correct word, as it is not really directly related to the existing profile stuff.
There is also lots more we can do with this, including per profile test resources, per profile TestContainer support, and probably more.