Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to modify AnnotatedType within test class #156

Open
dansiviter opened this issue Jul 31, 2023 · 5 comments
Open

Unable to modify AnnotatedType within test class #156

dansiviter opened this issue Jul 31, 2023 · 5 comments
Milestone

Comments

@dansiviter
Copy link

When trying to make an extension that auto injected mocks, I've ran into an issue where the test class cannot be modified through ProcessAnnotatedType extension event. I've created a test that replicates the issue here. It seems the test framework creates both a backed and unbacked version of MyTest class and the added @Inject annotation is lost. My intention is my just defining @Mock a @Singleton mock would be created and injected into the class, but it seems this isn't possible.

@manovotn
Copy link
Collaborator

manovotn commented Jul 31, 2023

Hi

Yes, I think the backed test class wasn't used in the actual test (i.e. the test instance you operate on was provided by junit); if memory serves, it was used to pick up producers and such.
There was some catch in the order in which junit was able to give Weld the information on test class and Weld being able to instantiate and feed it back to junit.
But that was on older version, newer versions of Junit might be able to help us workaround that and provide test instance in time.
Test instance factory might be the key - https://junit.org/junit5/docs/current/api/org.junit.jupiter.api/org/junit/jupiter/api/extension/TestInstanceFactory.html

@dansiviter
Copy link
Author

Just had a look and looks like it would be a pretty large rewrite. That's because it needs the test class instance to extract the WeldInitiator field to then subsequently start weld for @EnableWeld. It, therefore, wouldn't be able to use the test class instance managed by weld. This is somewhat less of an issue for @EnableAutoWeld as it doesn't permit a WeldInitiator instance.

@manovotn
Copy link
Collaborator

manovotn commented Aug 1, 2023

@dansiviter yes, that's the catch indeed.

I think this would be possible if we enforce that WeldInitiator has to be static.
That way we should be able to get needed information and still provide the instance in time. You could do scanning for WeldInitiator inside TestInstanceFactory#createTestInstance - which is also the place where we'd need to boot Weld container. We're currently booting in before-all/before-each (WRT chosen TestInstance.Lifecycle) which is way too late.

OFC this would be a massive breaking change for any tests using WeldInitiator which begs the question whether that's worth it given that the only gain is that the test instance would now be provided by Weld 🤷

@manovotn
Copy link
Collaborator

manovotn commented Aug 2, 2023

BTW this is similar to the discussion that took place in #144
The motivation behind the other issue was interception which boils down to the same thing - having class instance as a bean.

One notable thing we didn't mention here is that not all test classes can be beans per specification - apart from no-arg constructor, inner classes cannot become beans.

@manovotn
Copy link
Collaborator

manovotn commented Aug 2, 2023

I think the scope of these changes would be too breaking for current versions but we could do them for next major version (targeting future Weld/CDI release).

To implement the behavior you are looking for, you could also perform the injection manually. You can basically hook into any junit5 phase where you have the test instance object at your disposal and perform it there. Granted, it's not the best approach but the only I can think of without causing braking changes in Weld extension

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants