I have tried to walk through the jUnit source code a couple of times, trying to figure out how to implement my own behavior; only to give up in frustration (no I did not read the documentation, real developers don’t do that, they Google!) Why would I want to implement my own behavior? Well, it always seems to center around integrating with Spring. I usually want/need to do control the way the context is being created or do something immediately before the context is loaded or as the context is loading; something that might not be possible not possible using a @BeforeClass annotation.
This problem was actually related to my previous blog on Implementing Custom Scopes in Spring. Because I implemented some beans using the session scope, I kind of created a catch-22 scenario; I have tried to capture the problem in bullet form:
- Each jUnit test needs the ability to specify the specific test user (role, user info, etc.) that is relevant for that individual test
- The test user profiles are configured and controlled by a Spring managed bean
- All beans are lazy-init = true and injected into the unit test using the @Resource annotation
- The session scope beans need to have the SecurityContextHolder configured with the appropriate principal (test user), before they are created
- So, the problem is: How do you specify the test user, before the session scope beans are created and injected into the unit test class?
In a normal execution environment, using the Spring Security filters and a Servlet, the SecurityContextHolder would have been assigned using the authenticated principal, before creating any Spring dependencies. Because I created my own custom scopes for unit testing, the SecurityContextHolder was null and the session scope beans constructor was failing an assertion (principal != null). I could have easily fixed this by adding a pre-authenticated user to the SecurityContextHolder, using some static method approach,. However, because my mechanism for handling test users was itself a Spring bean, I had no possible way of specifying before the beans were injected into my unit test.
When jUnit 4.0 was released, it added several new constructs that make some very elegant solutions. I don’t think most developer’s ever look beyond the base jUnit functionality; fortunately it seems to solve 99% of the typical test scenarios. The new constructs are actually specified via annotations, they are the @RunWith and @TestExecutionListeners. My example code, can probably be made a little cleaner, but my main goal was to get the unit tests working. Because you don’t directly create any of these objects, you have to be aware of the timing; implement your customizations at the correct point in the lifecycle. Another interesting problem, is that you don’t actually create the Spring Context, but you can interact with it via listeners.
First, we need a class which extends DependencyInjectionTestExecutionListener. This base class is required when using Spring and provides several override-able methods. I needed to configure the SecurityContextHolder, before any beans were injected into the unit test; I could accomplish this by utilizing the injectDependencies method. To support my testing needs, I added two (2) properties to the sub-class (this could have been cleaner); one to specify a user from a “user provider” factory, and a simpler one that used the user id of the person running the test. As you can see from the code, before an beans are injected into the unit test, I have access to the Spring context. This allows me to request the “user provider” factory and then request a specific test user. At this point, I can now assign the user to the SecurityContextHolder; all before any of the session scope beans are created.
public class AuthorizedTestExecutionListener extends DependencyInjectionTestExecutionListener {
private TestUserAuthorization defaultAuthorization;
private String junitAuthorization;
public void setJunitAuthorization(final String junitAuthorization) {
this.junitAuthorization = junitAuthorization;
}
public void setDefaultAuthorization(final TestUserAuthorizationdefaultAuthorization) {
this.defaultAuthorization = defaultAuthorization;
}
@Override
@SuppressWarnings("PMD.SignatureDeclareThrowsException")
protected voidinjectDependencies(final TestContext testContext) throws Exception {
if (StringUtils.isNotBlank(junitAuthorization)) {
final Authentication login = new UnitTestAuthenticationToken(this.getClass().getSimpleName());
SecurityContextHolder.getContext().setAuthentication(login);
}
else if (defaultAuthorization != null) {
finalTestUserModuleManager manager = (TestUserModuleManager) testContext.getApplicationContext()
.getBean(defaultAuthorization.testUserManager());
final SecureUserInterface user = manager.find(defaultAuthorization.principal());
final Authentication login = new UnitTestAuthenticationToken(user);
SecurityContextHolder.getContext().setAuthentication(login);
}
super.injectDependencies(testContext);
}
}
Next, we need to extend SpringJUnit4ClassRunner. This class is responsible for for creating the Spring test context and DI listener class. By over-ridding the createTestContextManager, you have the opportunity to configure the test execution listeners. I also created two custom annotations, TestUserAuthentication and JUnitAuthentication. Using either one of these annotations, I could provide run-time meta-data to my custom AuthorizedSpringjUnit4ClassRunner; the meta data was then used to configure my custom AuthorizedTestExecutionListner.
public class AuthorizedSpringjUnit4ClassRunner extends SpringJUnit4ClassRunner {
public AuthorizedSpringjUnit4ClassRunner(final Class<?> clazz) throws InitializationError {
super(clazz);
}
@Override
@SuppressWarnings("PMD.ConfusingTernary")
protected TestContextManager createTestContextManager(final Class<?> clazz) {
final TestUserAuthorization defaultUser = clazz.getAnnotation(TestUserAuthorization.class);
final JUnitAuthorization jUnitUser = clazz.getAnnotation(JUnitAuthorization.class);
final TestContextManager context = super.createTestContextManager(clazz);
for (final TestExecutionListener l : context.getTestExecutionListeners()) {
if(AuthorizedTestExecutionListener.class.isAssignableFrom(l.getClass())) {
if (defaultUser !=null) {
((AuthorizedTestExecutionListener) l).setDefaultAuthorization(defaultUser);
}
else if (jUnitUser != null) {
((AuthorizedTestExecutionListener) l).setJunitAuthorization(clazz.getSimpleName());
}
}
}
return context;
}
}
Once you understand what all of the pieces do, they are super easy to customize to provide enhanced behavior. I think my solution provided a very clean, elegant solution for providing test specific user profiles, on a test by test basis.
@RunWith(AuthorizedSpringjUnit4ClassRunner.class)
@TestExecutionListeners(AuthorizedTestExecutionListener.class)
@ContextConfiguration(locations = {//
"/com/beilers/resources/spring/contexts/jUnitContext.xml" //
})
public class UnitTestHelper {
...
}
So, how do you deploy your application if Hudson is running on a different machine than your Tomcat instance? Fortunately, Hudson provides a plug-in to solve this problem, simply named the Deploy Plug-in. It supports a variety of containers, taking advantage of the Cargo Framework. Can’t get much easier than this, just point to your WAR file and fill in the container information. That’s it! I tried it out today and it worked perfectly. This was a much cleaner approach than adding the logic to the build process.
I recently found a plug-in that I wanted to share as well, called 
These are not really new features, but I bet most developers (like myself) have not given them the attention they deserve! Earlier this month, I read an interesting article on the
I was looking for a development build of the IvyDE plug-in for Eclipse tonight and I stumbled across the 
I recently worked on a JSF-based application that was integrated with Spring, both the Core Framework as well as the Spring Security Framework. I certainly don’t have it all mastered, but the experience has given me multiple topics to blog about! We decided to let Spring manage all of the beans, rather than making JSF manage some of the beans and Spring manager the rest. I liked the consistency and thought it would make unit testing easier. Spring provides two basic scopes, singleton and prototype. When you add Spring Security into the mix, you get two additional scopes, one for session and another for request. 
