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
If the current test classes provided in Spring have to be reused (as we do in Spring/OSGi), there are a few bumps which make extension hard.
One particular problem occurs in AbstractSingleSpringContextTests and AbstractDependencyInjectionSpringContextTests. The first class always expects an application context to be created even if no files/locations are specified which can lead to NPE problems or force an appCtx to be instantiated even if not needed.
Even if the first problem can be overcome, the second test will try to apply auto-injection; this can be disabled but it has to be done manually inside the onSetUp...
Basicaly, it would be nice to have a no-op behavior; if nothing is supplied then the functionality inside the test is not applied. Again this makes sense, if the test is used as a base class. Another solution would be to move some of the functionality outside the test class so new hierachies don't have to extend this one. However, this doesn't add a lot of benefits since in most cases, the functionality has to be applied on the test itself.
I have added your requested no-op behavior to the JUnit 3.8 legacy
testing support.
One particular problem occurs in AbstractSingleSpringContextTests and
AbstractDependencyInjectionSpringContextTests. The first class always
expects an application context to be created even if no files/locations
are specified which can lead to NPE problems or force an appCtx to be
instantiated even if not needed.
AbstractSpringContextTests: getContext(Object) now checks if the context
key is 'empty' before attempting to retrieve or load an ApplicationContext.
Even if the first problem can be overcome, the second test will try to
apply auto-injection; this can be disabled but it has to be done
manually inside the onSetUp...
AbstractDependencyInjectionSpringContextTests: prepareTestInstance() will
only call injectDependencies() if the ApplicationContext has actually been
configured.
Note that the new Spring TestContext Framework already supports similar
"no-op behavior" based on whether or not @ContextConfiguration is
present on the test class, etc. Thus if you are not restricted to using the
JUnit 3.8 legacy support, we recommend that you write all new integration
tests with the TestContext framework.
Uh oh!
There was an error while loading. Please reload this page.
Costin Leau opened SPR-3264 and commented
If the current test classes provided in Spring have to be reused (as we do in Spring/OSGi), there are a few bumps which make extension hard.
One particular problem occurs in AbstractSingleSpringContextTests and AbstractDependencyInjectionSpringContextTests. The first class always expects an application context to be created even if no files/locations are specified which can lead to NPE problems or force an appCtx to be instantiated even if not needed.
Even if the first problem can be overcome, the second test will try to apply auto-injection; this can be disabled but it has to be done manually inside the onSetUp...
Basicaly, it would be nice to have a no-op behavior; if nothing is supplied then the functionality inside the test is not applied. Again this makes sense, if the test is used as a base class. Another solution would be to move some of the functionality outside the test class so new hierachies don't have to extend this one. However, this doesn't add a lot of benefits since in most cases, the functionality has to be applied on the test itself.
Issue Links:
The text was updated successfully, but these errors were encountered: