AbstractSingleSpringContextTests - runBare vs final setUp() [SPR-3191]

[spring-projects-issues]

Costin Leau opened SPR-3191 and commented

Me again :)

I'm working on the OSGi test support which is similar to the one provided by Spring - however, I see that for some reason the setup and tearDown methods are final in c. Is there any reason for that?
Why not add the functionality inside runBare and leave setUp and tearDown methods untouched.

See http://www.martinfowler.com/bliki/CallSuper.html for an example - basically move the special test functionality inside runBare instead of setUp and tearDown which are quite heavily by application developers.

Another separate issue would be to extract the junit functionality into helper classes which can be reused by third parties - for example AbstractSpringContextTests adds caching functionality that could be extracted so if one has its own junit hierarchy it can reuse these instead of copying.
This has been mentioned a number of times by various customers/users which have their own infrastructure and can't easily reuse the context functionality.

---

Issue Links:

• no-op behavior for Junit classes [SPR-3264] #7949 no-op behavior for Junit classes ("is depended on by")

[spring-projects-issues]

Paul Benedict commented

Costin, in regards to your last paragraph, I believe extracting the functionality will help facilitate the move to JUnit 4. See #7229 for related information.

[spring-projects-issues]

Costin Leau commented

JUnit 4 or TestNG might help here but they will also break compatibility. Junit 3.8.1 is still widely used and I don't think it's going to disappear any time soon.

[spring-projects-issues]

Juergen Hoeller commented

Note that there are protected non-final "onSetUp" and "onTearDown" methods in AbstractSpringContextTests. The core JUnit hooks are simply final because of the template method pattern, to enforce the specialized callbacks.

Point taken on reuse of the code there; however, that's going to be hard, since the primary point of the current test classes are protected fields and methods. There is no easy way to provide this sort of convenient value-add without inheritance. So I'm afraid we might not be able to do much about this, other than copying the relevant code...

Juergen

[spring-projects-issues]

Costin Leau commented

Right, but I was wondering why not make move the functionality from setUp and tearDown into runBare and leave them untouched? One still gets the same benefit and doesn't have to 'learn' the newly added onXXX methods.

[spring-projects-issues]

Costin Leau commented

One small improvement to AbstractSingleSpringContextTests: the appCtx creation cannot be easily extended since it's hidden inside loadContextLocations and loadContextPaths (which doesn't seem to be used).
Extracting the new ClassPathXmlAppCtx inside one method would allow subclasses to change the appctx implementation (to a non-xml/classpath appCtx for example)

[spring-projects-issues]

Juergen Hoeller commented

I've decided to leave this as-is for the time being, since there are other issues with those test base classes as well. My bet for a cleaner, more flexible model is rather on the newly designed test framework for JUnit4 that Sam is working on now. For the existing base classes, their usage pattern is at least established already (has been the same for years), so there's no strong need to change it...

As for overriding the choice of ApplicationContext implementation: I'm afraid you'll indeed have to override "createApplicationContext" (or "loadContext" if you decide to use something other than a config location array as "contextKey"). This shouldn't be too bad in recent Spring versions, though. There's also no obvious way to factor out even more fine-granular context creation there, as far as I see.

Juergen