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

Expose test method to test instance constructor extensions #3670

Closed
3 tasks
michaeldimchuk opened this issue Jan 31, 2024 · 4 comments
Closed
3 tasks

Expose test method to test instance constructor extensions #3670

michaeldimchuk opened this issue Jan 31, 2024 · 4 comments

Comments

@michaeldimchuk
Copy link

I know this was previously discussed on #1568, but the discussion wasn't conclusive and the team seemed open to the change, so I'd like to re-open it for feedback.

This change would involve the test method being passed to all test instance construction related extensions, TestInstanceFactory, TestInstancePreConstructCallback and TestInstancePreDestroyCallback.

An example description of why this would be helpful is here: quarkusio/quarkus#38336.

The summary is that some frameworks (like Quarkus) allow for the CDI container to be configured by the test method when the test lifecycle is PER_METHOD, like to override configuration properties for a specific test case, before initializing the container. This allows for beans customized to a specific test case to be injected into the class, with all the appropriate configurations already applied.

This is possible with a fully mutable test class where Quarkus can use BeforeEach and AfterEach to set up / tear down the container before the tests run and ensure all beans are injected, but that breaks down when all fields in the class are final.
Just as an example, I usually set lombok.config settings lombok.fieldDefaults.defaultFinal and lombok.fieldDefaults.defaultPrivate to true, so all fields are private and final by default in the entire project, including all tests, which then means I have to disable that by putting @FieldDefaults(makeFinal = false) on each test class using that functionality, which is a bit inconvenient (and keeping fields mutable isn't my preference).

If the test method was passed to the test instance factory extensions, then this would allow for a CDI container to be configured on a per test basis while at the same time maintaining an immutable class.

Deliverables

  • TestInstanceFactory#createTestInstance should receive the test method through ExtensionContext#getTestMethod
  • TestInstancePreConstructCallback#preConstructTestInstance should receive the test method through ExtensionContext#getTestMethod
  • TestInstancePreDestroyCallback#preDestroyTestInstance should receive the test method through ExtensionContext#getTestMethod
@sbrannen
Copy link
Member

sbrannen commented Feb 3, 2024

@michaeldimchuk, isn't this effectively a duplicate of #3445?

@michaeldimchuk
Copy link
Author

It could be, I created a separate issue because it may be a different feature request depending on how #3445 would be implemented. The main request in that issue is for the ExtensionContext to be scoped to a single test case when using the PER_METHOD lifecycle, which does not necessarily imply the need to pass the test method itself into it.

However if the test method would be available as part of that solution, then yeah, I'd be happy to close this as a duplicate.

Copy link

If you would like us to be able to process this issue, please provide the requested information. If the information is not provided within the next 3 weeks, we will be unable to proceed and this issue will be closed.

@sbrannen
Copy link
Member

However if the test method would be available as part of that solution, then yeah, I'd be happy to close this as a duplicate.

I think that would almost have to be the case.

In light of that, I am closing this issue as a duplicate, and I'll add a note to #3445 to point out that this issue should also be taken into account in the implementation.

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

No branches or pull requests

2 participants