Simplifying Spring Integration testing

It seems like last week that I would happily write things like "public abstract class BaseMyCompanyTest extends AbstractTransactionalDatasourceSpringContextTests {" and think I was the man. It seems like yesterday that Spring 2.5 came along and made things a lot easier with @ContextConfiguration. But now I find myself grinding against the boilerplate again.

Before I start tearing it down let me first tell you that I highly respect the work by Sam Brannen and that I have gotten very good mileage out it for over two years now. There is always room for improvement and that is the aim of the following experiment.

The TestContext framework that comes with Spring might be very useful, it is also quite complex. You can only use it with a custom testrunner and and you need to pass the location of the configurations to be loaded in a class level annotation. This means it is non trivial and asymmetric to load multiple contexts in a single test. Also the incantations you have to put on the class are not exactly concise (although they are much better than the AbstractTooFreakinLongClassNames options of old).

Since JUnit 4.7 there is @Rule. And you can do some pretty cool stuff with it. When combining it with Spring though I wasn't impressed. I felt that Spring Test was making it hard to use the power of Rules. This is ironic, since it is just this JUnit feature that would make Spring Test a lot better.

How cool would it be if you could write:

1 2 3 4 5

@Rule   public TemporarySpringContext context = new TemporarySpringContext("context.xml");   @Autowired   ApplicationContext thisShouldBeWired;

And it would just work?

Gues what, I've got a green test that says it does! It only took me 50 lines of code, which you can find in my spring sandbox on github.

The important class is this the TemporarySpringContext (which I might give a better name soon):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

public class TemporarySpringContext extends TestWatchman {   /** * Cache of Spring application contexts. This needs to be static, as tests * are typically destroyed and recreated between running individual test methods. */   static final ContextCache contextCache = new ContextCache();   private ConfigurableApplicationContext context;   private final String[] contextLocations;   public TemporarySpringContext(String... contextLocations) {     this.contextLocations = contextLocations;     try {       context = contextCache.contextForLocations(contextLocations);     } catch (Exception e) {       throw new RuntimeException(e);     }   }   @Override   public Statement apply(Statement base, FrameworkMethod method, Object target) {     context.getAutowireCapableBeanFactory().autowireBean(target);     return super.apply(base, method, target);   }   public ConfigurableApplicationContext getContext() {     return context;   }      public void dirtyContext(){     contextCache.markDirty(contextLocations);   } }

Because it extends TestWatchman you can hook into al the phases of your test by simply overriding a method. Because it is just a MethodRule field you can add different contexts to your test class. There is plenty of room to polish this, but it has more potential than the SpringJUnit4ClassRunner I think.

Since most of the heavy lifting is still being done by Spring Test behind the scenes by the way. The ContextCache is the only complex part (yet) but I have some tricks to pull to make @Transactional and such work. If you fix it before me I owe you a beer :)

Posted via email from iweinfuld's posterous