One of the greatest benefits of Spring MVC is that it removes your dependency on a servlet container. In theory, you should be able to test your controllers, and your entire web stack, from a testing harness like JUnit. In reality, you become just as dependent on the wonderful services offered by DispatcherServlet and a complete WebApplicationContext (request parameter binding, validation, model attributes, request mappings, and aspects such as Spring Security). In this article, I will show you how to create a mock servlet context and WebApplicationContext from within JUnit.

The trick to making this happen is to create a custom ContextLoader. This can be used by your JUnit tests as follows:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations="classpath:spring.xml",
		loader=MockWebApplicationContextLoader.class)
@MockWebApplication(name="some-controller")
public class SomeControllerTests {
	...
}

The ContextLoader will be given the opportunity to load an application context and create a servlet environment for our tests before they are run. To facilitate this we create the MockWebApplication annotation to allow your tests to configure certain properties such as the servlet name and the path to the webapp directory.

The Context Loader

The source code for the MockWebApplicationContextLoader should be pretty straightforward. Let’s step through it quickly. First, we set up a ServletContext and ServletConfig using Spring’s mock implementations and the MockWebApplication as a source for their configuration. Then we create and configure an XmlWebApplicationContext. Finally, we create an instance of DispatcherServlet and configure it with our ServletConfig and ApplicationContext.

It is worth taking special note of the following code:

webApplicationContext.addBeanFactoryPostProcessor(new BeanFactoryPostProcessor() {
	@Override
	public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
		beanFactory.registerResolvableDependency(DispatcherServlet.class, dispatcherServlet);
		// Register any other beans here, including a ViewResolver if you are using JSPs.
	}
});

Here, we register the DispatcherServlet as a bean in our context. This is so that it can be injected into our test classes and used to perform the integration tests. If you would like to register additional beans in your context this is where you would do it.

The View

If you are using Java Server Pages for your view layer you need to be aware of a limitation. JSPs are dependent on the servlet container and cannot be tested this way. As such, you will need to create and register a stub ViewResolver that does nothing. Furthermore, you will not be able to test your JSPs.

If at all possible, I would strongly recommend the use of an alternative technology such as Freemarker or Velocity. They are not dependent on a servlet container. As such, you’ll be able to test the template files from JUnit. This allows you to verify that all of your expressions, variable names, externalized messages, etc.

If you are using JSP tag libraries from FreeMarker, see this post for a small problem you will encounter and how to work around it.

In this example we will be using FreeMarker.

Example Tests

Let’s look at some example tests. The complete source code can be found here. Because we registered the DispatcherServlet in the context, it will be injected into our test classes:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations="classpath:spring.xml",
		loader=MockWebApplicationContextLoader.class)
@MockWebApplication(name="some-controller")
public class SomeControllerTests {
	@Autowired
	private DispatcherServlet servlet;
}

Now we can test a request to GET /view?id=0:

@Test
public void viewTest() throws ServletException, IOException {
	MockHttpServletRequest request = new MockHttpServletRequest("GET", "/view");
	request.addParameter("id", "0");
	MockHttpServletResponse response = new MockHttpServletResponse();

	servlet.service(request, response);
	String results = response.getContentAsString().trim();

	Assert.assertEquals("<html><body>Hello World!</body></html>", results);
}

We do this by constructing a MockHttpServletRequest and MockHttpServletResponse (both a part of Spring) and passing them to the DispatcherServlet. We can get the results of the request (if we are not using JSPs) from the response object.

There are significant advantages to testing a web application this way. In particular, you can prepare your data model before issuing a request and inspect it afterwards for changes:

@Test
public void saveTest() throws ServletException, IOException {
	MockHttpServletRequest request = new MockHttpServletRequest("POST", "/");
	request.addParameter("name", "Ted");
	MockHttpServletResponse response = new MockHttpServletResponse();

	servlet.service(request, response);

	Assert.assertEquals("Ted", repository.find(1).getName());
}

And because we have a fully configured web stack we can test other services such as security. Here’s an example of accessing a secured portion of our website without authentication:

@Test(expected=NestedServletException.class)
public void secureFailedTest() throws ServletException, IOException {
	MockHttpServletRequest request = new MockHttpServletRequest("GET", "/secure/view");
	MockHttpServletResponse response = new MockHttpServletResponse();

	servlet.service(request, response);
}

Unlike using an external website testing tool we do not need to go through the tedious process of logging into account and keeping track of cookies. Instead, we can explicitly establish the user and its authorities directly with the Spring Security API:

@Test
public void secureTest() throws ServletException, IOException {
	SecurityContextHolder.getContext().setAuthentication(new UsernamePasswordAuthenticationToken("ted", "password"));

	MockHttpServletRequest request = new MockHttpServletRequest("GET", "/secure/view");
	MockHttpServletResponse response = new MockHttpServletResponse();

	servlet.service(request, response);
	String results = response.getContentAsString().trim();

	Assert.assertEquals("<html><body>Hello Secure!</body></html>", results);
}

Advantages over Other Tools

Most people, when tasked with creating automated tests for a web application, reach for tools such as JMeter that act as user agents interacting with the application. While these tools are very useful, for performance testing, our solution with JUnit has many advantages for functional testing.

In particular, because the tests are run within the same virtual machine as our application and within the same application context it is much easier to develop targeted, easy to maintain tests which can explicitly establish a model prior to a test and verify the model after the test. Furthermore, sequences of tests do not need to rely on parsing or scraping HTML output to determine subsequent URLs.

Finally, because the tests are developed using JUnit, they can run from continuous integration software, run from common build tools, and participate in code coverage.

References

I want to thank Tejus for giving me a head start on this.  Unfortunately, his prototype didn’t include complete source code and examples.  And I saw the chance to make some minor improvements on performance and functionality. So, I set out to write this.