Provide a way to create custom ApplicationContextFactory in SpringBootContextLoader

[FyiurAmron]

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.

[philwebb]

I'm not too keen on adding a new attribute to @SpringBootTest but I wonder if we could make SpringBootContextLoader easier to subclass.

@FyiurAmron If the existing getApplicationContextFactory method was protected would that meet your needs?

[FyiurAmron]

@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