There are two types of testing that developers typically perform before they release code into production. Functional testing is the testing you do when your application is mostly built and you want to make sure that everything works according to the functional requirements you were given.

Unit testing is the process by which you test each component of your application in isolation. Unit testing can be done far in advance of functional testing and code release. EJBs are difficult to unit test because it is cumbersome to tease them apart from the container for testing. Spring makes unit testing easy because each component is intended to be an entity unto itself – callable from anywhere.

Unit testing is an important part of the development process, so important in fact that some methodologies, including Agile ^[6] , require that the unit test be written before the class that it will be testing. Certainly writing the unit test first will give you a very clear idea of the use case for your class file. But the real value in unit testing is in giving you the ability to isolate where the problems may lie in your code. This will shorten the amount of time you would need to debug your code and ultimately lead to faster time to production.

As you create your unit tests, you may organize them into test suites. There are several third party and open source products that can help you set up and conduct your unit tests. JUnit (http://www.junit.org) is the most popular unit testing framework and can be integrated with Ant, Maven, the Eclipse IDE, and others. Maven (http://maven.apache.org) is a build framework used for compiling, assembling jars, and running unit tests. All of the examples that accompany this book can be built and tested using Maven, and Eclipse plugins for Junit allow you to run your unit tests from within the IDE.

Spring also has unit testing support and it can reduce the size of your test classes if you can use them. Most unit tests in the examples extend AbstractSingleSpringContextTests. It sets up an ApplicationContext that can be used during each test. It also has a setDirty() method to reload the context if a test has changed something that will cause other tests to fail.

                
package org.springbyexample.springindepth.chapter02.springApplication;

import static org.junit.Assert.assertEquals;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;

import org.springbyexample.springindepth.test.AbstractCoreSpringTestBase;
import org.springbyexample.springindepth.test.chapter02.AbstractSingleSpringContextTests;

/**
 * Unit test Spring container creating the message bean.
 */
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"/applicationContext.xml"})
public class MessageTest {

    final Logger logger = LoggerFactory.getLogger(MessageTest.class);
    
    /**
     * Tests bean message for expected message.
     */
    @Test
    public void testMessage() {
        Message message = (Message) applicationContext.getBean("message");

        logger.debug("message='" + message.getMessage() + "'");

        assertEquals("Message is not '" + AbstractMessageTestBase.MESSAGE + "'.", 
                     AbstractMessageTestBase.MESSAGE, 
                     message.getMessage());
    }

}