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 {
...
}
I like anything that gives Apple a little jab… and am looking forward to Verizon releasing some interesting new phones. Verizon just created a new sub-site, http://www.verizonwireless.com/droid. I think it is actually a pretty good campaign, “iDon’t”. I have been using Windows Mobile for many years, and I will be the first to say that it has be be considered a complete failure; but similar to the old Palm OS, there have always been a multitude of free applications with no Steve restrictions. My primary need for a Windows-based phone was the integration with Outlook, which allowed me to sync my calendar, contacts, email, etc; which did work flawlessly. I have never been into the whole Android thing, as I am no fan of “single” source solutions, such as that iThing. But, now that Verizon and several other carriers are planning to release phones, and even Acer has released a new Android-based netbook, I’m starting to get a little more interested! 
I know it is a couple of days late, but it is hard to think about resolutions when you are traveling! On the way back from Ohio, I heard a statistic on the radio that said over 50% of people don’t even bother with New Years Resolutions anymore. The primary reason for not making a resolution was because they knew they would not succeed. That seems kind of sad, doesn’t it? Yet another old tradition that is going by the wayside, as society changes for the better(?). What bothers me most, is that I thought New Year’s resolutions were the one time a year where everyone had the chance to think about making some small changes in their lives for the better. Hopefully making them better or healthier people, or maybe even doing something that would make the world a better place.
We just got back from a week long vacation in Ohio with my parents. We had a really nice time with the family, but it never takes long to remember why I moved to Virginia…. winter! Check out the truck, can you say salt? It was amazing to see all of the cars and trucks from Michigan, Ohio, and Pennsylvania, coated in white. No wonder you see so many rusted out old cars and trucks! What a difference a little soap and water makes! The truck looks pretty good for being nine years old, it only has about 80 thousand miles on it. Now that gas is back to a reasonable price, we can actually afford to drive it again!
I’m no gamer, but when you have have two boys (13 and 11), you can avoid it! We purchased an XBox 360 last year for Christmas… can you say “excited” kids? Anyway, that XBox lasted about two (2) weeks and we were introduced the the “Red Ring of Death”… Sounds like a really cool video game, right? Unfortunately, it means your XBox is toast! We returned it and decided to buy another one from Best Buy, only because they offered an extended warranty. Normally, we do not buy the warranty, but if you do a Google search on XBox reliablity, and you will see thousands of pages of people with issues…. I hoped it would be money well spent, at least it would make it easier on the kids.
