First off: Don’t load your Spring Context in your tests unless you absolutely have to. Some integration tests should load it, but keep it to a minimum. Loading the context is expensive, especially if you load up Hibernate and maybe H2 in that context.

Avoid loading the context is important both for speed and design. I have seen way too many tests where the context is loaded just because someone don’t want to do mocking. Besides, if you have to do a lot of mocking your design is usually too coupled, and should be changed.

So how can you speed up your tests in Maven?

• Put them in a suite
• And make sure they load the same context. Not the actual context object, but an array of strings of the context files in the same order and file names. See http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/test/AbstractSingleSpringContextTests.html#getConfigLocations().

Spring will cache the context and make sure it is only loaded once. But due to details I have not studied; in Maven, this only works for the tests that are in the same suite. It should work with fork=once on the surefire-plugin, but for some reason we need the suites too. Test which one works for you.

Drawbacks? If there is state in your context (database, stateful services) you will have created a dependency between your tests. That’s why, when it comes to database-testing you should use the AbstractTransactionalSpringContextTests which will automatically roll back your changes at the end of your tests. If state is modified in a way that has nothing to do with your database use setDirty() to signal to Spring that the context should be recreated for the next test. Of course then you get the time penalty of recreation.

What it does is use the test-coverage that it was originally written to do, to figure out which tests exercise which classes. So when you change Class1 and Class2 it knows which that Test1, Test2, Test3 and Test4 need to be rerun to check if you have broken anything.

I did an initial test on our build which takes almost 10 minutes. I’m of the slightly paranoid type so I like to run the full build to verify my changes, at least before I check in. With changes in one class Clover figured it should rerun about 20 tests, and ran in about 4 minutes. That’s 6 minutes saved many times a day for each developer. We’re not using it at our build server just yet, but trying to save time for each developer before commit.

Any downsides? Of course. The initial time (mvn clean removes all info) to build is almost doubled for my project. You won’t catch all errors, and updates to dependencies won’t be caught. And there is a problem handling deleted classes. For some reason it creates a optimized-src directory which is a copy of all your sources and compiles from there. If you delete a class in your src folder it won’t be deleted in optimized-src and you could get compilation errors. After some initial tests it seems these problems are bigger in theory than they are in real day situations.

Using Clover should be no excuse bad tests though. I know all too well how I can really mess up my own tests. The long test times often stem from our inability to focus on testing the logic separately from infrastructure as databases or external services. And of course loading the Spring context is done way too much. But that’s stuff for another post.

But even if you have good unit tests there will be time to save. And everything that can keep me from getting distracted when developing is a good thing.

I’ll give this a good run until the 30 day trial licence expires, and maybe invest. Maybe we will see something similar in Cobertura too…

Update: It looks like it is also activated when doing mvn eclipse:eclipse . Because it redefines the source folders to target/clover/src-optimized this is also what is written in you Eclipse project. So be sure to have an easy way to disable running if you’re going to use this.

As they put it:

JavaRebel is a developer tool that will reload changes to compiled Java classes on-the-fly saving the time that it takes to redeploy an application or perform a container restart. It is a generic solution that works for Java EE and Java standalone applications.!

Promise me to have a look at their screancasts (found on the right hand side of the page). They also have a nice list of features and supported JVM’s and web-containers.

They also have a Google group that answers questions you may have.

I haven’t tried it yet but am truely looking forward to it:-)
And if you do, please post a comment and let me know how it went.

Update: Spring JavaConfig M3 is released.

To check out some comments about the further process and an explanation of some of the core concepts, check out this blog entry.

I am slowly coming to my senses seeing how much benefit newer features like generics, static imports and annotations are bringing to the game. I used to think that these features were nice to have, but didn’t revolutionize the way we develop our applications. After seeing how Jmock2, Guice, Quaré and others use new features to change the way we code I am beginning to see the light.

I didn’t use to think the Spring xml files were that bad either, but now I really need to look into the Spring Java config API.

Who knows, I might even look into Ruby one of these days. (I would probably miss my type saftety though)

• Integrating systems are only available inside the firewall. Sometimes it is relevant to test and develop outside our normal network.
• Different integrating systems have different availability. You can’t rely on all of them beeing available all the time.

To overcome these we want to be able to stub the integrating systems. But introducing stubs also leads to some complications:

• The test team needs to be able to check which systems are stubbed and which systems have real integration when testing.
• The test team will need different configurations at different times, and I’m too lazy to package 20 installations.

So what I need is:

• A webinterface to display the status of the integration points (stub or real implementation)
• A webinterface to change which points are stubbed or not

The solution

Since we are using Spring all the wiring and configuration is stored in XML files, and I could probably manipulate files on the disk, but it didn’t sound like an attractive solution. After asking a bit around at the java.no forum I settled on a proxy based solution in the spirit of Spring’s LocalStatelessSessionProxyFactoryBean. Implementation was easy enough, and it seems to work. In it’s essence it is a proxy and a proxyfactory wrapped in one class (FactoryBean and MethodInterceptor is implemented) that handles which class will be invoked (stub/real).

It also has some shortcomings that you should be aware of:

• No security as to who can use it
• It is not tested with proxies inside the proxy, but I guess that will work.
• You should probably restart your app before making config changes. Any state in the beans real/stub will be missing when switching.

The config

The config should be pretty self explanatory with two beans, one interface and one boolean injected into the ProxyFactory. The stubEnabled boolean could be omitted. It defaults to running the real implementation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<bean id="myService" class="IntegrationPointProxyFactoryBean">
  <property name="businessInterface">
    <value>MyService</value>
  </property>
  <property name="stubImplementation">
    <bean class="MyServiceStubImpl" />
  </property>
  <property name="realImplementation">
    <bean class="MyServiceImpl" />
  </property>
  <property name="stubEnabled">
    <value>true</value>
  </property>
</bean>

The proxy

The proxy is the object that sits around the real and stub implementations. It will direct the execution to the correct bean depending on it’s settings.

The signature looks like this (the larger methods impls is further down):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class IntegrationPointProxyFactoryBean implements FactoryBean, MethodInterceptor, InitializingBean {
	/* Required interface methods. See Spring docs for info. */
	public Object getObject() {
		return this.proxy;
	}
	public boolean isSingleton() {
		return false;
	}
	public Class getObjectType() {
		if (this.proxy == null) {
			return this.businessInterface;
		} else {
			return this.proxy.getClass();
		}
	}
	public Object invoke(MethodInvocation invocation) throws SecurityException, NoSuchMethodException, IllegalArgumentException, IllegalAccessException, InvocationTargetException;
	public void afterPropertiesSet();
 
	/* New methods specific for this bean */
	public void setBusinessInterface(Class businessInterface);
	public void setRealImplementation(Object realImplementation);
	public void setStubImplementation(Object stubImplementation);
	public void setStubEnabled(boolean stubEnabled);
}

The set* methods are just plain old dependency injection methods that sets a class variable, I won’t write about them. To make the solution better you might want to do some before/after consistency checks in them. The interesting stuff happens in the afterPropertiesSet and invoke methods.

afterPropertiesSet

1
2
3
4
5
6

public void afterPropertiesSet() {
	/* A bunch of consistency checks for null etc */
 
	// Initialise the proxyobject which is this object
	this.proxy = ProxyFactory.getProxy(this.businessInterface, this);
}

Thats pretty much all you need to do to create a proxy with Springs utilities. The object you are assigning as the proxy must implement the MethodInterceptor interface.

That was the config, the rest of the stuff happens runtime in the invoke method.

invoke

1
2
3
4
5
6
7
8
9
10
11
12

public Object invoke(MethodInvocation invocation) throws SecurityException, NoSuchMethodException, IllegalArgumentException, IllegalAccessException, InvocationTargetException {
	Method aopMethod = invocation.getMethod();
	Object runObject = null;
	if (this.stubEnabled) {
		runObject = this.stubImplementation;
	} else {
		runObject = this.realImplementation;
	}
	Method classInvocation = runObject.getClass().getMethod(aopMethod.getName(), aopMethod.getParameterTypes());
 
	return classInvocation.invoke(runObject, invocation.getArguments());
}

The controller

This is all nice and dandy, but it won’t do you much good if you don’t have something to control and display this behaviour. You need a controller doing the following:

• Retrieve all beans of type IntegrationProxtFactoryBean and pass them to the JSP
• If enabled, switch implementation between real and stub

IntegrationPointController

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class IntegrationPointController extends AbstractController {
	protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) {
		Map beans = this.getApplicationContext().getBeansOfType(IntegrationPointProxyFactoryBean.class);
 
		// Switch implementasjon
		if (request.getParameter("point") != null) {
			String pointName = request.getParameter("point");
			IntegrationPointProxyFactoryBean pointBean = (IntegrationPointProxyFactoryBean) beans.get(pointName);
			pointBean.setStubEnabled(!pointBean.isStubEnabled());
		}
 
		Map model = new HashMap();
		model.put("points", beans);
 
		return new ModelAndView("config/showPoints", model);
	}
}

And the JSP is something like this (not the prettiest code, but this is just util stuff anyway):

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

<c :forEach items="${points}" var="point">
  <div style="border: 1px solid black; padding: 1em; margin: 1em">
    <strong>Name:</strong>
    <c :out value="${point.key}" />
    <br />
    <strong>Real:</strong>
    <c :if test="!${point.value.stubEnabled}">
      <span style="color: red">
        <c :out value="${point.value.realImplementationInjected}" />
        <c :if test="${!point.value.stubEnabled}"></c>
        <br />
        <strong>Stub:</strong>
        <c :if test="${point.value.stubEnabled}">
          <span style="color: green">
            <c :out value="${point.value.stubImplementationInjected}" />
            <c :if test="${point.value.stubEnabled}"></c>
            <br />
            <c :if test="${point.value.switchable}">[ 
            <a href="&lt;c:url value=">
            <c :param name="point"
            value="${point.key}" />"&gt;Switch</a>]</c>
          </span>
        </c>
      </span>
    </c>
  </div>
</c>

This is the first time I try to do such an extensive article, I hope it turned out alright. Let me know if you think otherwise.