You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it currently stands, SpringBootContextLoader creates the contexts using the 0-arg c-tors, which in turn use the this.beanFactory = new DefaultListableBeanFactory(); from GenericApplicationContext; beanFactory is private and final, so as a result there is basically no simple way to inject a custom BeanFactory to the test context (or at least there is none that I am aware of).
While it might seem that it should be enough for the custom BeanFactory to be tested in isolation, sometimes it's the integration with any conforming GenericApplicationContext subclass itself that needs to be tested (as it is in my case e.g.). Obviously, it's still possible to provide a completely custom context to tests, but for that to integrate well and to adhere to POLA it requires rewriting/copy-pasting sizeable parts of SpringBootContextLoader - while e.g. a simple annotation or annotation param to e.g. @SpringBootTest allowing to provide a class name of the custom BeanFactory would make this trivial, and shouldn't require too much additional code in SpringBootContextLoader.
And yes, this is a rare use case, but still I believe there is nothing to be lost by providing this functionality somehow, and in general having more flexibility in testing envs is always beneficial IMO. I do understand that this might get the lowest-than-low priority though, so while I'm no SB expert I can try doing a PR for this if it gets greenlit (guidelines welcome in that case), just to see how it works out.
The text was updated successfully, but these errors were encountered:
@philwebb yes, I think it would do the trick; I completely understand your objections here, so I guess that just having an option to override that single method via protected while keeping the rest intact would be a reasonable solution - that'd be just a couple of lines of easily-manageable subclass implementation instead of a ~600 lines of copy-paste needed to be kept in sync with upstream :D
philwebb
changed the title
provide a way to inject custom BeanFactory in SpringBootContextLoader
Provide a way to inject custom BeanFactory in SpringBootContextLoader
Nov 7, 2023
philwebb
changed the title
Provide a way to inject custom BeanFactory in SpringBootContextLoader
Provide a way to create custom ApplicationContextFactory in SpringBootContextLoader
Nov 7, 2023
As it currently stands,
SpringBootContextLoader
creates the contexts using the 0-arg c-tors, which in turn use thethis.beanFactory = new DefaultListableBeanFactory();
fromGenericApplicationContext
;beanFactory
is private and final, so as a result there is basically no simple way to inject a custom BeanFactory to the test context (or at least there is none that I am aware of).While it might seem that it should be enough for the custom BeanFactory to be tested in isolation, sometimes it's the integration with any conforming
GenericApplicationContext
subclass itself that needs to be tested (as it is in my case e.g.). Obviously, it's still possible to provide a completely custom context to tests, but for that to integrate well and to adhere to POLA it requires rewriting/copy-pasting sizeable parts of SpringBootContextLoader - while e.g. a simple annotation or annotation param to e.g.@SpringBootTest
allowing to provide a class name of the custom BeanFactory would make this trivial, and shouldn't require too much additional code in SpringBootContextLoader.And yes, this is a rare use case, but still I believe there is nothing to be lost by providing this functionality somehow, and in general having more flexibility in testing envs is always beneficial IMO. I do understand that this might get the lowest-than-low priority though, so while I'm no SB expert I can try doing a PR for this if it gets greenlit (guidelines welcome in that case), just to see how it works out.
The text was updated successfully, but these errors were encountered: