Do want to get a better understanding of Spring web application architecture? If so, get started right now!

Unit Testing of Spring MVC Controllers: Configuration

Pistons and crankshaft

Writing unit tests for Spring MVC controllers has traditionally been both simple and problematic.

Although it is pretty simple to write unit tests which invoke controller methods, the problem is that those unit tests are not comprehensive enough.

For example, we cannot test controller mappings, validation and exception handling just by invoking the tested controller method.

Spring MVC Test solved this problem by giving us the possibility to invoke controller methods through the DispatcherServlet.

This is the first part of my tutorial which describes the unit testing of Spring MVC controllers and it describes how we can configure our unit tests.

Let’s get started.

Getting the Required Dependencies with Maven

We can get the required dependencies by declaring the following testing dependencies in our pom.xml file:

  • JUnit 4.11
  • Mockito Core 1.9.5
  • Spring Test 3.2.3.RELEASE

The relevant part of our pom.xml file looks as follows:

<dependency>
	<groupId>junit</groupId>
	<artifactId>junit</artifactId>
	<version>4.11</version>
	<scope>test</scope>
</dependency>
<dependency>
	<groupId>org.mockito</groupId>
	<artifactId>mockito-core</artifactId>
	<version>1.9.5</version>
	<scope>test</scope>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-test</artifactId>
	<version>3.2.3.RELEASE</version>
	<scope>test</scope>
</dependency>

Note: If you have to use Spring Framework 3.1, you can write unit tests for your controllers by using spring-test-mvc. This project was included in the spring-test module when Spring Framework 3.2 was released.

Let’s move on and take a quick look at our example application.

The Anatomy of Our Example Application

The example application of this tutorial provides CRUD operations for todo entries. In order to understand the configuration of our test class, we must have some knowledge about the tested controller class.

At this point, we need to know the answers to these questions:

  • What dependencies does it have?
  • How is it instantiated?

We can get the answers to those questions by taking a look at the source code of the TodoController class. The relevant part of the TodoController class looks as follows:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.MessageSource;
import org.springframework.stereotype.Controller;

@Controller
public class TodoController {

    private final TodoService service;

    private final MessageSource messageSource;

    @Autowired
    public TodoController(MessageSource messageSource, TodoService service) {
        this.messageSource = messageSource;
        this.service = service;
    }

	//Other methods are omitted.
}

As we can see, our controller class has two dependencies: TodoService and MessageSource. Also, we can see that our controller class uses constructor injection.

At this point this is all there information we need. Next we will talk about our application context configuration.

Configuring the Application Context

Maintaining a separate application context configurations for our application and our tests is cumbersome. Also, It can lead into problems if we change something in the application context configuration of our application but forget to do the same change for our test context.

That is why the application context configuration of the example application has been divided in a such way that we can reuse parts of it in our tests.

Our application context configuration has been divided as follows:

  • The first application configuration class is called ExampleApplicationContext and it is the “main” configuration class of our application.
  • The second configuration class is responsible of configuring the web layer of our application. The name of this class is WebAppContext and it is the configuration class which we will use in our tests.
  • The third configuration class is called PersistenceContext and it contains the persistence configuration of our application.

Note: The example application has also a working application context configuration which uses XML configuration files. The XML configuration files which correspond with the Java configuration classes are: exampleApplicationContext.xml, exampleApplicationContext-web.xml and exampleApplicationContext-persistence.xml.

Let’s take a look at the application context configuration of our web layer and find out how we can configure our test context.

Configuring the Web Layer

The application context configuration of the web layer has the following responsibilities:

  1. It enables the annotation driven Spring MVC.
  2. It configures the location of static resources such as CSS files and Javascript files.
  3. It ensures that the static resources are served by the container’s default servlet.
  4. It ensures that the controller classes are found during component scan.
  5. It configures the ExceptionResolver bean.
  6. It configures the ViewResolver bean.

Let’s move on and take a look at the Java configuration class and the XML configuration file.

Java Configuration

If we use Java configuration, the source code of the WebAppContext class looks as follows:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.ViewResolver;
import org.springframework.web.servlet.config.annotation.DefaultServletHandlerConfigurer;
import org.springframework.web.servlet.config.annotation.EnableWebMvc;
import org.springframework.web.servlet.config.annotation.ResourceHandlerRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurerAdapter;
import org.springframework.web.servlet.handler.SimpleMappingExceptionResolver;
import org.springframework.web.servlet.view.InternalResourceViewResolver;
import org.springframework.web.servlet.view.JstlView;

import java.util.Properties;

@Configuration
@EnableWebMvc
@ComponentScan(basePackages = {
        "net.petrikainulainen.spring.testmvc.common.controller",
        "net.petrikainulainen.spring.testmvc.todo.controller"
})
public class WebAppContext extends WebMvcConfigurerAdapter {

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/static/**").addResourceLocations("/static/");
    }

    @Override
    public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
        configurer.enable();
    }

    @Bean
    public SimpleMappingExceptionResolver exceptionResolver() {
        SimpleMappingExceptionResolver exceptionResolver = new SimpleMappingExceptionResolver();

        Properties exceptionMappings = new Properties();

        exceptionMappings.put("net.petrikainulainen.spring.testmvc.todo.exception.TodoNotFoundException", "error/404");
        exceptionMappings.put("java.lang.Exception", "error/error");
        exceptionMappings.put("java.lang.RuntimeException", "error/error");

        exceptionResolver.setExceptionMappings(exceptionMappings);

        Properties statusCodes = new Properties();

        statusCodes.put("error/404", "404");
        statusCodes.put("error/error", "500");

        exceptionResolver.setStatusCodes(statusCodes);

        return exceptionResolver;
    }

    @Bean
    public ViewResolver viewResolver() {
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();

        viewResolver.setViewClass(JstlView.class);
        viewResolver.setPrefix("/WEB-INF/jsp/");
        viewResolver.setSuffix(".jsp");

        return viewResolver;
    }
}

XML Configuration

If we use XML configuration, the content of the exampleApplicationContext-web.xml file looks as follows:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:mvc="http://www.springframework.org/schema/mvc"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
       http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.1.xsd
       http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">

    <mvc:annotation-driven/>

    <mvc:resources mapping="/static/**" location="/static/"/>
    <mvc:default-servlet-handler/>

    <context:component-scan base-package="net.petrikainulainen.spring.testmvc.common.controller"/>
    <context:component-scan base-package="net.petrikainulainen.spring.testmvc.todo.controller"/>

    <bean id="exceptionResolver" class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">
        <property name="exceptionMappings">
            <props>
                <prop key="net.petrikainulainen.spring.testmvc.todo.exception.TodoNotFoundException">error/404</prop>
                <prop key="java.lang.Exception">error/error</prop>
                <prop key="java.lang.RuntimeException">error/error</prop>
            </props>
        </property>
        <property name="statusCodes">
            <props>
                <prop key="error/404">404</prop>
                <prop key="error/error">500</prop>
            </props>
        </property>
    </bean>

    <bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
        <property name="prefix" value="/WEB-INF/jsp/"/>
        <property name="suffix" value=".jsp"/>
        <property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>
    </bean>
</beans>

Configuring the Test Context

The configuration of our test context has two responsibilities:

  1. It configures a MessageSource bean which is used by our controller class (feedback messages) and Spring MVC (validation error messages). The reason why we need to do this is that the MessageSource bean is configured in the “main” configuration class (or file) of our application context configuration.
  2. It creates a TodoService mock which is injected to our controller class.

Let’s find out how we configure our test context by using Java configuration class and XML configuration file.

Java Configuration

If we configure our test context by using Java configuration, the source code of the TestContext class looks as follows:

import org.mockito.Mockito;
import org.springframework.context.MessageSource;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.support.ResourceBundleMessageSource;

@Configuration
public class TestContext {

    @Bean
    public MessageSource messageSource() {
        ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();

        messageSource.setBasename("i18n/messages");
        messageSource.setUseCodeAsDefaultMessage(true);

        return messageSource;
    }

    @Bean
    public TodoService todoService() {
        return Mockito.mock(TodoService.class);
    }
}

XML Configuration

If we configure our test context by using an XML configuration, the content of the testContext.xml file looks as follow:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
        <property name="basename" value="i18n/messages"/>
        <property name="useCodeAsDefaultMessage" value="true"/>
    </bean>

    <bean id="todoService" name="todoService" class="org.mockito.Mockito" factory-method="mock">
        <constructor-arg value="net.petrikainulainen.spring.testmvc.todo.service.TodoService"/>
    </bean>
</beans>

Configuring The Test Class

We can configure our test class by using one of the following options:

  1. The Standalone configuration allows us to register one or more controllers (classes annotated with the @Controller annotation) and configure the Spring MVC infrastructure programatically. This approach is a viable option if our Spring MVC configuration is simple and straight-forward.
  2. The WebApplicationContext based configuration allows us the configure Spring MVC infrastructure by using a fully initialized WebApplicationContext. This approach is better if our Spring MVC configuration is so complicated that using standalone configuration does not make any sense.

Let’s move on and find out how we can configure our test class by using both configuration options.

Using Standalone Configuration

We can configure our test class by following these steps:

  1. Annotate the class with the @RunWith annotation and ensure that test is executed by using the MockitoJUnitRunner.
  2. Add a MockMvc field to the test class.
  3. Add a TodoService field to the test class and annotate the field with the @Mock annotation. This annotation marks the field as a mock. The field is initialized by the MockitoJUnitRunner.
  4. Add a private exceptionResolver() method to the class. This method creates a new SimpleMappingExceptionResolver object, configures it, and returns the created object.
  5. Add a private messageSource() method to the class. This method creates a new ResourceBundleMessageSource object, configures it, and returns the created object.
  6. Add a private validator() method to the class. This method creates a new LocalValidatorFactoryBean object and returns the created object.
  7. Add a private viewResolver() method to the the class. This method creates a new InternalResourceViewResolver object, configures it, and returns the created object.
  8. Add a setUp() method to the test class and annotate the method with the @Before annotation. This ensures that the method is invoked before each test. This method creates a new MockMvc object by calling the standaloneSetup() method of the MockMvcBuilders class and configures the Spring MVC infrastructure programmatically.

The source code of our test class looks as follows:

import org.junit.Before;
import org.junit.runner.RunWith;
import org.mockito.Mock;
import org.mockito.runners.MockitoJUnitRunner;
import org.springframework.context.MessageSource;
import org.springframework.context.support.ResourceBundleMessageSource;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.setup.MockMvcBuilders;
import org.springframework.validation.beanvalidation.LocalValidatorFactoryBean;
import org.springframework.web.servlet.HandlerExceptionResolver;
import org.springframework.web.servlet.ViewResolver;
import org.springframework.web.servlet.handler.SimpleMappingExceptionResolver;
import org.springframework.web.servlet.view.InternalResourceViewResolver;
import org.springframework.web.servlet.view.JstlView;

import java.util.Properties;

@RunWith(MockitoJUnitRunner.class)
public class StandaloneTodoControllerTest {

    private MockMvc mockMvc;

    @Mock
    private TodoService todoServiceMock;

    @Before
    public void setUp() {
        mockMvc = MockMvcBuilders.standaloneSetup(new TodoController(messageSource(), todoServiceMock))
                .setHandlerExceptionResolvers(exceptionResolver())
                .setValidator(validator())
                .setViewResolvers(viewResolver())
                .build();
    }

    private HandlerExceptionResolver exceptionResolver() {
        SimpleMappingExceptionResolver exceptionResolver = new SimpleMappingExceptionResolver();

        Properties exceptionMappings = new Properties();

        exceptionMappings.put("net.petrikainulainen.spring.testmvc.todo.exception.TodoNotFoundException", "error/404");
        exceptionMappings.put("java.lang.Exception", "error/error");
        exceptionMappings.put("java.lang.RuntimeException", "error/error");

        exceptionResolver.setExceptionMappings(exceptionMappings);

        Properties statusCodes = new Properties();

        statusCodes.put("error/404", "404");
        statusCodes.put("error/error", "500");

        exceptionResolver.setStatusCodes(statusCodes);

        return exceptionResolver;
    }

    private MessageSource messageSource() {
        ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();

        messageSource.setBasename("i18n/messages");
        messageSource.setUseCodeAsDefaultMessage(true);

        return messageSource;
    }

    private LocalValidatorFactoryBean validator() {
        return new LocalValidatorFactoryBean();
    }

    private ViewResolver viewResolver() {
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();

        viewResolver.setViewClass(JstlView.class);
        viewResolver.setPrefix("/WEB-INF/jsp/");
        viewResolver.setSuffix(".jsp");

        return viewResolver;
    }
}

Using the standalone configuration has two problems:

  1. Our test class looks like a mess even though our Spring MVC configuration is rather simple. Naturally, we could clean it up by moving the creation of Spring MVC infrastructure components into a separate class. This is left as an exercise for the reader.
  2. We have to duplicate the configuration of Spring MVC infrastructure components. This means that if we change something in the application context configuration of our application, we must remember to do the same change to our tests as well.

Using WebApplicationContext Based Configuration

We can configure our test class by following these steps:

  1. Annotate the test class with the @RunWith annotation and ensure that the test is executed by using the SpringJUnit4ClassRunner.
  2. Annotate the class with the @ContextConfiguration annotation and ensure that the correct configuration classes (or XML configuration files) are used. If we want to use Java configuration, we have to set the configuration classes as the value of the classes attribute. On the other hand, if we prefer XML configuration, we have to set the configuration files as the value of the locations attribute.
  3. Annotate the class with the @WebAppConfiguration annotation. This annotation ensures that the application context which is loaded for our test is a WebApplicationContext.
  4. Add a MockMvc field to the test class.
  5. Add a TodoService field to the test class and annotate the field with the @Autowired annotation.
  6. Add a WebApplicationContext field to the test class and annotate the field with the @Autowired annotation.
  7. Add a setUp() method to the test class and annotate the method with the @Before annotation. This ensures that the method is called before each test. This method has responsibilities: it resets the service mock before each test and create a new MockMvc object by calling the webAppContextSetup() method of the MockMvcBuilders class.

The source code of our test class looks as follows:

import org.junit.Before;
import org.junit.runner.RunWith;
import org.mockito.Mockito;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import org.springframework.test.context.web.WebAppConfiguration;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.setup.MockMvcBuilders;
import org.springframework.web.context.WebApplicationContext;

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {TestContext.class, WebAppContext.class})
//@ContextConfiguration(locations = {"classpath:testContext.xml", "classpath:exampleApplicationContext-web.xml"})
@WebAppConfiguration
public class WebApplicationContextTodoControllerTest {

    private MockMvc mockMvc;

    @Autowired
    private TodoService todoServiceMock;

    @Autowired
    private WebApplicationContext webApplicationContext;

    @Before
    public void setUp() {
        //We have to reset our mock between tests because the mock objects
        //are managed by the Spring container. If we would not reset them,
        //stubbing and verified behavior would "leak" from one test to another.
        Mockito.reset(todoServiceMock);

        mockMvc = MockMvcBuilders.webAppContextSetup(webApplicationContext).build();
    }
}

The configuration of our test class looks a lot cleaner than the configuration which uses standalone configuration. However, the “downside” is that our test uses the full Spring MVC infrastructure. This might be an overkill if our test class really uses only a few components.

Summary

We have now configured our unit test class by using both the standalone setup and the WebApplicationContext based setup. This blog post has taught us two things:

  • We learned that it is important to divide the application context configuration in a such way that we can reuse parts of it in our tests.
  • We learned the difference between the standalone configuration and the WebApplicationContext based configuration.

The next part of this tutorial describes how we can write unit tests for “normal” Spring MVC controllers.

P.S. The example application of this blog post is available at Github.

If you want to learn more about Spring MVC Test, you should read my Spring MVC Test tutorial.

About the Author

Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

About Petri Kainulainen →

27 comments… add one

  • I love SpringMVC. Since controllers are also POJO’s, testing is easy just like testing any other class. And have options like pointed above

    Reply
  • Thank’s! Very structured and easy to understand!

    Reply
    • You are welcome! I am happy to hear that this blog post was useful to you.

      Reply
  • Nice, thanks for showing how to set MockMvc’s view resolver programatically.

    Reply
  • Maybe you should also mention (or did you and I overlooked it?) that this project is usable even if you are stuck with a spring version lower than 3.2.x.
    Just use this project (its basically the same as this code base has been imported into the core).

    https://github.com/spring-projects/spring-test-mvc

    Reply
    • Actually I didn’t realize that it would be useful to mention it here. I will update this blog post later today. Thanks for pointing this out!

      Reply
  • Thanks for this post,

    I have a little question though :
    In the setUp() method which is executed before each test (@before), a MockMvc is built.
    I totally understant why the todoServiceMock has to be reset before each test, but what about the MockMvc ?
    Would it not be better to build the MockMvc once for all the tests (@beforeClass) ?
    What’s the point/utility of rebuilding a MockMvc before each test of the test class ?

    Maybe i missed something here, i’m relatively new to spring mocking strategy :)

    Reply
    • That is a GREAT question. To be honest, I create a new MockMvc object for each test case just because this is the way it is done in the reference manual of Spring Framework.

      However, now that you mentioned it, I started to wonder if this is really necessary. Unfortunately I cannot answer to your question right now, but I promise that I will try to find an answer to your question. I will let you know if I find it.

      Reply
      • Actually I’ve seen both ways. After a little research in spring sources, I saw it two times in the @beforeClass. So I guess it’s ok.

        Example :
        https://github.com/spring-projects/spring-test-mvc/blob/master/src/test/java/org/springframework/test/web/server/samples/context/WarRootDirectoryTests.java

        Anyway, thank you, these tutorials have been and will be really helpful.

        Reply
        • After I gave this some thought and did some testing, I noticed that using the @BeforeClass annotation isn’t very handy for two reasons:

          1. You have to remember to reset your mock objects in your test methods. If you don’t do this, your tests will fail when you try to verify the interactions between the tested code and the mock objects.
          2. You cannot inject anything to your test classes because all injected fields are null when the setUp() method is invoked. This means that you cannot use the WebApplicationContext based setup (unless you build the web application context yourself). Of course you can always use the standalone setup as long as you remember to reset your mock objects in your test methods.

          In other words, it seems that

          • It is possible to write unit tests by using this approach but it takes some extra work.
          • It doesn’t make sense to write integration tests by using this approach because it takes too much work to configure everything manually.
          Reply
          • I did some testing too. And yeah, with the @beforeClass approach I noticed the same issues as you. I’m back to the MockMvc in the @before method.

            Thank you for taking some time to take a look a this and give the proper answer to my question.

          • You are welcome! It is always nice to help someone out (and often I end up learning new things as well).

  • hai petri, thanks for structured explanation of the spring web Mvc
    could plz explain why spring come into picture ? what problems java faced before spring frame work ? And how spring solved those problems ?

    Reply
    • IMO the main reason why the Spring Framework became popular was that EJB 2 sucked big time. Writing EJB 2 applications was a complex task and the only way to configure them was to use monstrous XML files. In other words, the only other option, which provided “everything”, was so horrible that developers started to use Spring Framework for writing enterprise applications.

      You might want to read an article titled: Why Use the Spring Framework. However, you should remember that things have changed a lot, and the newer Java EE versions are totally different beasts.

      Reply
  • Hi Petri,

    I was following along pretty well until the Test Context configuration. Firstly, at the start of this tutorial I saw that our TodoController declared a TodoService variable. I assumed that the TodoService class would be covered at some time in the tutorial, but it was not. So I lost you on this part: .

    Am I missing something? Where is the TodoService class code? or did I miss a code download somewhere?

    Thanks

    Reply
    • Hi Tyler,

      The reason why I didn’t describe the TodoService interface in this blog post was that you don’t have to know what it is (yet).

      The next parts of this tutorial shed some light to this matter by describing the implementations of the tested controller methods. This tells you what service methods you have to mock in your unit tests.

      By the way, you can get the example application of this blog post from Github.

      Reply
  • Hey Petri!

    Excellent Tutorial!

    I have an issue for which I request your help.

    By default, the @WebApplicationContext looks for the main spring XML file in src/main/webapp in a maven project. How do we configure it for non-maven projects.

    I tried this:

    @ContextConfiguration({ “classpath*:mvc-dispatcher-servlet.xml” })
    @RunWith(SpringJUnit4ClassRunner.class)
    @WebAppConfiguration({ “classpath*:mvc-dispatcher-servlet.xml” } )
    public class LoginControllerTest {
    // some code
    }

    Reply
    • If the mvc-dispatcher-servlet.xml file is found from the “root” of your classpath, you can configure your test by using this code:

      
      @ContextConfiguration({"classpath:mvc-dispatcher-servlet.xml"})
      @RunWith(SpringJUnit4ClassRunner.class)
      @WebAppConfiguration
      public class LoginControllerTest {
      // some code
      }
      
      

      Check out the following Javadocs for more details about this:

      I hope that this answered to your question.

      Reply
  • Hi Petri,
    Above code with spring 4.0.5 , gives “java.lang.NoClassDefFoundError: javax/servlet/SessionCookieConfig” exception with below servlet api maven dependency

    javax.servlet
    servlet-api
    3.0-alpha-1
    provided

    Issue was fixed by including maven dependency for “geronimo-servlet_3.0_spec” (ref. https://jira.spring.io/browse/SPR-11049)

    Reply
    • This was very helpful! Thank you

      Reply
  • Hi Petri,

    I used your tutorial for setting up Spring Social and am now trying to unit test following this tutorial. The problem I am running into is that Spring-Social’s SocialConfiguration class that we extend to setup the social side of the house has a method “usersConnectionRepository” which calls the SocialConfigurer.getUsersConnectionRepository(connectionFactoryLocator. Obviously I don’t want a JDBCConnectionFactory being setup and called for unit tests but when I add a bean class to override it in my TestContext class Spring throws an exception say it found 2 matching beans and expected only one. Any help you can provide is appreciated.

    Reply
  • Thanks, nice post

    Reply
  • Hello Petri,
    Thanks for the post. I have been following the same.
    I am writing unit test based on java config approach.
    I am able to deploy and test the application via rest client such as postman.
    But with Junit I am not sure why I am getting the below error. Is this a configuration problem. Please let me know your input.
    Kind Regards
    Sanjeev.

    
    @RunWith(SpringJUnit4ClassRunner.class)
    @WebAppConfiguration
    @ContextConfiguration(classes = {PersistenceConfigODB.class, RootConfig.class, WebConfig.class})
    public class TeamRepositoryTest {
    	private MockMvc mockMvc;
    	
    	@Autowired
    	WebApplicationContext webApplicationContext;
    
    	@BeforeClass
    	public static void setUpBeforeClass() throws Exception {}
    
    	@Before
    	public void setUp() throws Exception {
    		mockMvc = MockMvcBuilders
    						.webAppContextSetup(webApplicationContext)
    						.build();
    	}
    }
    
    

    java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/servlet/SessionTrackingMode

    Update: I removed the unrelated part of the stack trace – Petri

    Reply
    • I found this blog post which describes a very similar problem and provides a solution to it.

      Is the servlet-api jar file in the classpath when you run your unit tests?

      Reply
  • Why test code is far longer than code to be tested ?
    Isn’t it a little problem ?
    Who says more code, says more bugs, isn’t it ?
    Anyway good job

    Reply
    • Why test code is far longer than code to be tested ?

      If you are referring to the test methods described in the second and third part of this tutorial, the reason is that those methods test too much. Nowadays I split the test methods into smaller test methods which test only one thing.

      But I think that it is quite common that the LOC of your test code is a lot bigger than the LOC of your production code. This happens if you write comprehensive tests for your code.

      Isn’t it a little problem ?

      Yes. The test methods described in later parts of this tutorial should be splitted into smaller methods.

      Who says more code, says more bugs, isn’t it ?

      Yes. That is why I split my test methods into smaller methods. These methods are typically much simpler which makes it easier to verify that there are no bugs.

      Anyway good job

      Thanks. Also, thank you for asking this important question.

      Reply

Leave a Comment