-
Notifications
You must be signed in to change notification settings - Fork 38.3k
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
Improve extensibility of TestContext bootstrap and context caching mechanisms [SPR-12683] #17282
Comments
Lari Hotari commented created #732 that adds the constructor. |
Lari Hotari commented it looks like it would also help if DefaultCacheAwareContextLoaderDelegate, DefaultBootstrapContext and DefaultTestContext were public classes. |
Sam Brannen commented This is related to #17281. |
David Erickson commented I too would love to see improvement here, two particular things that would have been very useful to me recently:
|
Sam Brannen commented Can you please provide more information on why you need to supply your own Is the What is the difference between the Thanks in advance for feedback, Sam |
Sam Brannen commented Similarly, can you please explain why you would like for Cheers, Sam |
Sam Brannen commented
Can you please expound on the concrete use case you have in mind? Specifically, what is it you wish you achieve that you cannot currently? Thanks, Sam |
Sam Brannen commented The reason I'm requesting the aforementioned feedback from you is that I need insight into your concrete requirements in order to refactor and/or redesign the mechanisms in a manner that is best for the community and longevity of the Spring TestContext Framework. Regards, Sam |
Lari Hotari commented Sam, The use case I have is https://jira.grails.org/browse/GRAILS-11963 . Grails has it's own unit testing intrastructure and I was going to use TestContextManager for managing the test context. I was trying to programmaticly use the TCF to instantiate and control a test context. It wasn't possible to programmaticly control and extend TCF to be used in Grails unit test runtime. I know it's not originally designed to be used like that but making small changes would have solved the problem I faced in my Grails use case. I'm sorry I cannot recall more accurate details than what I've described in this the issue details of this issue #17282 and #17281. I don't work on Grails as a full time paid developer any more so I won't be able to provide more feedback now. |
David Erickson commented Sam Brannen, Thanks, edit - I also have a hacked up prototype version of this if it would be useful, I dropped you an email on this a couple of months back. |
Sam Brannen commented Resolved in the following commits: Highlights:
|
Sam Brannen commented Hi guys, Please take a look at the recent commits related to this issue and let me know if these changes cover your use cases. Thanks, Sam |
Lari Hotari opened SPR-12683 and commented
Currently it's not possible to provide a
TestContext
orTestContextBootstrapper
instance toTestContextManager
. This restricts the reusability of it.I'm currently working on GRAILS-11963 ("Use Spring TestContext Framework for initializing the test context") for Grails 3, and we would like to reuse as much as possible from the Spring TCF.
As a fix, there should be a new constructor that allows passing
TestContext
andTestContextBootstrapper
instances to theTestContextManager
- for example:Something should be done to the
ContextCache contextCache
field, since that is static and has package visibility. TheContextCache
class isn't a public class either. Perhaps that could be separated fromTestContextManager
?Affects: 4.1 GA
Issue Links:
Referenced from: commits 5cbe4b9, 9e6a5ae, c52a0cc, 129488c, 0392a88, 186abcb, c9d597f, e6c24f7
1 votes, 3 watchers
The text was updated successfully, but these errors were encountered: