Test with JUnit

A test case is simply a public method with the @Test annotation. To set up data, you can annotate a method with @Before. To clean up resources, you can annotate a method with @After. You can also annotate a public static method with @BeforeClass or @AfterClass to have it run once before or after all test cases in the class.

You have to call the static assert methods declared in the org.junit.Assert class directly. However, you can import all assert methods via a static import statement. You can create the following JUnit test cases to test your simple interest calculator.

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
</dependency>

testCompile 'junit:junit:4.12'

package com.apress.springrecipes.bank;

import static org.junit.Assert.*;

import org.junit.Before;
import org.junit.Test;

public class SimpleInterestCalculatorJUnit4Tests {

    private InterestCalculator interestCalculator;

    @Before
    public void init() {
        interestCalculator = new SimpleInterestCalculator();
        interestCalculator.setRate(0.05);
    }

    @Test
    public void calculate() {
        double interest = interestCalculator.calculate(10000, 2);
        assertEquals(interest, 1000.0, 0);
    }

    @Test(expected = IllegalArgumentException.class)
    public void illegalCalculate() {
        interestCalculator.calculate(-10000, 2);
    }
}

JUnit offers a powerful feature that allows you to expect an exception to be thrown in a test case. You can simply specify the exception type in the expected attribute of the @Test annotation.

Test with TestNG

A TestNG test looks similar to a JUnit test, except that you have to use the classes and annotation types defined by the TestNG framework.

<dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>6.11</version>
</dependency>

testCompile 'org.testng:testng:6.11'

package com.apress.springrecipes.bank;

import static org.testng.Assert.*;

import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;

public class SimpleInterestCalculatorTestNGTests {

    private InterestCalculator interestCalculator;

    @BeforeMethod
    public void init() {
        interestCalculator = new SimpleInterestCalculator();
        interestCalculator.setRate(0.05);
    }

    @Test
    public void calculate() {
        double interest = interestCalculator.calculate(10000, 2);
        assertEquals(interest, 1000.0);
    }

    @Test(expectedExceptions = IllegalArgumentException.class)
    public void illegalCalculate() {
        interestCalculator.calculate(-10000, 2);
    }
}

One of the powerful features of TestNG is its built-in support for data-driven testing. TestNG cleanly separates test data from test logic so that you can run a test method multiple times for different data sets. In TestNG, test data sets are provided by data providers, which are methods with the @DataProvider annotation.

package com.apress.springrecipes.bank;

import org.testng.annotations.BeforeMethod;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;

import static org.testng.Assert.assertEquals;

public class SimpleInterestCalculatorTestNGTests {

    private InterestCalculator interestCalculator;

    @BeforeMethod
    public void init() {
        interestCalculator = new SimpleInterestCalculator();
        interestCalculator.setRate(0.05);
    }

    @DataProvider(name = "legal")
    public Object[][] createLegalInterestParameters() {
        return new Object[][]{new Object[]{10000, 2, 1000.0}};
    }

    @DataProvider(name = "illegal")
    public Object[][] createIllegalInterestParameters() {
        return new Object[][]{
            new Object[]{-10000, 2},
            new Object[]{10000, -2},
            new Object[]{-10000, -2}
        };
    }

    @Test(dataProvider = "legal")
    public void calculate(double amount, double year, double result) {
        double interest = interestCalculator.calculate(amount, year);
        assertEquals(interest, result);
    }

    @Test(
        dataProvider = "illegal",
        expectedExceptions = IllegalArgumentException.class)
    public void illegalCalculate(double amount, double year) {
        interestCalculator.calculate(amount, year);
    }
}

If you run the preceding test with TestNG , the calculate() method will be executed once, while the illegalCalculate() method will be executed three times, as there are three data sets returned by the illegal data provider.

Create Unit Tests for Isolated Classes

The core functions of your bank system should be designed around customer accounts. First, you create the following domain class, Account, with custom equals() and hashCode() methods:

package com.apress.springrecipes.bank;

public class Account {

    private String accountNo;
    private double balance;

    // Constructors, Getters and Setters                
    ...

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Account account = (Account) o;
        return Objects.equals(this.accountNo, account.accountNo);
    }

    @Override
    public int hashCode() {
        return Objects.hash(this.accountNo);
    }
}

Next, you define the following DAO interface for persisting account objects in your bank system’s persistence layer:

package com.apress.springrecipes.bank;

public interface AccountDao {

    public void createAccount(Account account);
    public void updateAccount(Account account);
    public void removeAccount(Account account);
    public Account findAccount(String accountNo);
}

To demonstrate the unit testing concept, let’s implement this interface by using a map to store account objects. The AccountNotFoundException and DuplicateAccountException classes are subclasses of RuntimeException that you should be able to create yourself.

package com.apress.springrecipes.bank;

import java.util.Collections;
import java.util.HashMap;
import java.util.Map;

public class InMemoryAccountDao implements AccountDao {

    private Map<String, Account> accounts;

    public InMemoryAccountDao() {
        accounts = Collections.synchronizedMap(new HashMap<String, Account>());
    }

    public boolean accountExists(String accountNo) {
        return accounts.containsKey(accountNo);
    }

    public void createAccount(Account account) {
        if (accountExists(account.getAccountNo())) {
            throw new DuplicateAccountException();
        }
        accounts.put(account.getAccountNo(), account);
    }

    public void updateAccount(Account account) {
        if (!accountExists(account.getAccountNo())) {
            throw new AccountNotFoundException();
        }
        accounts.put(account.getAccountNo(), account);
    }

    public void removeAccount(Account account) {
        if (!accountExists(account.getAccountNo())) {
            throw new AccountNotFoundException();
        }
        accounts.remove(account.getAccountNo());
    }

    public Account findAccount(String accountNo) {
        Account account = accounts.get(accountNo);
        if (account == null) {
            throw new AccountNotFoundException();
        }
        return account;
    }
}

Obviously, this simple DAO implementation doesn’t support transactions. However, to make it thread-safe, you can wrap the map storing accounts with a synchronized map so that it will be accessed serially.

Now, let’s create unit tests for this DAO implementation with JUnit. As this class doesn’t depend directly on other classes, it’s easy to test. To ensure that this class works properly for exceptional cases as well as normal cases, you should also create exceptional test cases for it. Typically, exceptional test cases expect an exception to be thrown.

package com.apress.springrecipes.bank;

import static org.junit.Assert.*;

import org.junit.Before;
import org.junit.Test;

public class InMemoryAccountDaoTests {

    private static final String EXISTING_ACCOUNT_NO = "1234";
    private static final String NEW_ACCOUNT_NO = "5678";

    private Account existingAccount;
    private Account newAccount;
    private InMemoryAccountDao accountDao;

    @Before
    public void init() {
        existingAccount = new Account(EXISTING_ACCOUNT_NO, 100);
        newAccount = new Account(NEW_ACCOUNT_NO, 200);
        accountDao = new InMemoryAccountDao();
        accountDao.createAccount(existingAccount);
    }

    @Test
    public void accountExists() {
        assertTrue(accountDao.accountExists(EXISTING_ACCOUNT_NO));
        assertFalse(accountDao.accountExists(NEW_ACCOUNT_NO));
    }

    @Test
    public void createNewAccount() {
        accountDao.createAccount(newAccount);
        assertEquals(accountDao.findAccount(NEW_ACCOUNT_NO), newAccount);
    }

    @Test(expected = DuplicateAccountException.class)
    public void createDuplicateAccount() {
        accountDao.createAccount(existingAccount);
    }

    @Test
    public void updateExistedAccount() {
        existingAccount.setBalance(150);
        accountDao.updateAccount(existingAccount);
        assertEquals(accountDao.findAccount(EXISTING_ACCOUNT_NO), existingAccount);
    }

    @Test(expected = AccountNotFoundException.class)
    public void updateNotExistedAccount() {
        accountDao.updateAccount(newAccount);
    }

    @Test
    public void removeExistedAccount() {
        accountDao.removeAccount(existingAccount);
        assertFalse(accountDao.accountExists(EXISTING_ACCOUNT_NO));
    }

    @Test(expected = AccountNotFoundException.class)
    public void removeNotExistedAccount() {
        accountDao.removeAccount(newAccount);
    }

    @Test
    public void findExistedAccount() {
        Account account = accountDao.findAccount(EXISTING_ACCOUNT_NO);
        assertEquals(account, existingAccount);
    }

    @Test(expected = AccountNotFoundException.class)
    public void findNotExistedAccount() {
        accountDao.findAccount(NEW_ACCOUNT_NO);
    }
}                                                                                      

Create Unit Tests for Dependent Classes Using Stubs and Mock Objects

Testing an independent class is easy, because you needn’t consider how its dependencies work and how to set them up properly. However, testing a class that depends on results of other classes or services (e.g., database services and network services) would be a little bit difficult. For example, let’s consider the following AccountService interface in the service layer:

package com.apress.springrecipes.bank;

public interface AccountService {

    void createAccount(String accountNo);
    void removeAccount(String accountNo);
    void deposit(String accountNo, double amount);
    void withdraw(String accountNo, double amount);
    double getBalance(String accountNo);
}

The implementation of this service interface has to depend on an AccountDao object in the persistence layer to persist account objects. The InsufficientBalanceException class is also a subclass of RuntimeException that you have to create.

package com.apress.springrecipes.bank;

public class AccountServiceImpl implements AccountService {

    private AccountDao accountDao;

    public AccountServiceImpl(AccountDao accountDao) {
        this.accountDao = accountDao;
    }

    public void createAccount(String accountNo) {
        accountDao.createAccount(new Account(accountNo, 0));
    }

    public void removeAccount(String accountNo) {
        Account account = accountDao.findAccount(accountNo);
        accountDao.removeAccount(account);
    }

    public void deposit(String accountNo, double amount) {
        Account account = accountDao.findAccount(accountNo);
        account.setBalance(account.getBalance() + amount);
        accountDao.updateAccount(account);
    }

    public void withdraw(String accountNo, double amount) {
        Account account = accountDao.findAccount(accountNo);
        if (account.getBalance() < amount) {
            throw new InsufficientBalanceException();
        }
        account.setBalance(account.getBalance() - amount);
        accountDao.updateAccount(account);
    }

    public double getBalance(String accountNo) {
        return accountDao.findAccount(accountNo).getBalance();
    }
}

A common technique in unit testing to reduce complexity caused by dependencies is to use stubs. A stub must implement the same interface as the target object so that it can substitute for the target object. For example, you can create a stub for AccountDao that stores a single customer account and implements only the findAccount() and updateAccount() methods, as they are required for deposit() and withdraw().

package com.apress.springrecipes.bank;

import static org.junit.Assert.*;

import org.junit.Before;
import org.junit.Test;

public class AccountServiceImplStubTests {

    private static final String TEST_ACCOUNT_NO = "1234";
    private AccountDaoStub accountDaoStub;
    private AccountService accountService;

    private class AccountDaoStub implements AccountDao {

        private String accountNo;
        private double balance;

        public void createAccount(Account account) {}
        public void removeAccount(Account account) {}

        public Account findAccount(String accountNo) {
            return new Account(this.accountNo, this.balance);
        }

        public void updateAccount(Account account) {
            this.accountNo = account.getAccountNo();
            this.balance = account.getBalance();
        }
    }

    @Before
    public void init() {
        accountDaoStub = new AccountDaoStub();
        accountDaoStub.accountNo = TEST_ACCOUNT_NO;
        accountDaoStub.balance = 100;
        accountService = new AccountServiceImpl(accountDaoStub);
    }

    @Test
    public void deposit() {
        accountService.deposit(TEST_ACCOUNT_NO, 50);
        assertEquals(accountDaoStub.accountNo, TEST_ACCOUNT_NO);
        assertEquals(accountDaoStub.balance, 150, 0);
    }

    @Test
    public void withdrawWithSufficientBalance() {
        accountService.withdraw(TEST_ACCOUNT_NO, 50);
        assertEquals(accountDaoStub.accountNo, TEST_ACCOUNT_NO);
        assertEquals(accountDaoStub.balance, 50, 0);
    }

    @Test(expected = InsufficientBalanceException.class)
    public void withdrawWithInsufficientBalance() {
        accountService.withdraw(TEST_ACCOUNT_NO, 150);
    }
}

However, writing stubs yourself requires a lot of coding . A more efficient technique is to use mock objects. The Mockito library is able to dynamically create mock objects that work in a record/playback mechanism.

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <version>2.7.20</version>
    <scope>test</scope>
</dependency>

testCompile 'org.mockito:mockito-core:2.7.20'

package com.apress.springrecipes.bank;

import org.junit.Before;
import org.junit.Test;

import static org.mockito.Mockito.*;

public class AccountServiceImplMockTests {

    private static final String TEST_ACCOUNT_NO = "1234";

    private AccountDao accountDao;
    private AccountService accountService;

    @Before
    public void init() {
        accountDao = mock(AccountDao.class);
        accountService = new AccountServiceImpl(accountDao);
    }
                                                                                          
    @Test
    public void deposit() {
        // Setup                
        Account account = new Account(TEST_ACCOUNT_NO, 100);
        when(accountDao.findAccount(TEST_ACCOUNT_NO)).thenReturn(account);

        // Execute                
        accountService.deposit(TEST_ACCOUNT_NO, 50);

        // Verify                
        verify(accountDao, times(1)).findAccount(any(String.class));
        verify(accountDao, times(1)).updateAccount(account);

    }

    @Test
    public void withdrawWithSufficientBalance() {
        // Setup                
        Account account = new Account(TEST_ACCOUNT_NO, 100);
        when(accountDao.findAccount(TEST_ACCOUNT_NO)).thenReturn(account);

        // Execute                
        accountService.withdraw(TEST_ACCOUNT_NO, 50);

        // Verify                
        verify(accountDao, times(1)).findAccount(any(String.class));
        verify(accountDao, times(1)).updateAccount(account);

    }

    @Test(expected = InsufficientBalanceException.class)
    public void testWithdrawWithInsufficientBalance() {
        // Setup                
        Account account = new Account(TEST_ACCOUNT_NO, 100);
        when(accountDao.findAccount(TEST_ACCOUNT_NO)).thenReturn(account);

        // Execute                
        accountService.withdraw(TEST_ACCOUNT_NO, 150);
    }
}

With Mockito, you can create a mock object dynamically for an arbitrary interface or class. This mock can be instructed to have certain behavior for method calls, and you can use it to selectively verify whether something has happened. In your test you want that in the findAccount method that a certain Account object is returned. You use the Mockito.when method for this, and you can then either return a value, throw an exception, or do more elaborate things with an Answer. The default behavior for the mock is to return null. You use the Mockito.verify method to do selective verification of actions that should have happened. You want to make sure that the findAccount method is called and that the account gets updated.

Create Integration Tests

Integration tests are used to test several units in combination to ensure that the units are properly integrated and can interact correctly. For example, you can create an integration test to test AccountServiceImpl using InMemoryAccountDao as the DAO implementation.

package com.apress.springrecipes.bank;

import static org.junit.Assert.*;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

public class AccountServiceTests {

    private static final String TEST_ACCOUNT_NO = "1234";
    private AccountService accountService;

    @Before
    public void init() {
        accountService = new AccountServiceImpl(new InMemoryAccountDao());
        accountService.createAccount(TEST_ACCOUNT_NO);
        accountService.deposit(TEST_ACCOUNT_NO, 100);
    }

    @Test
    public void deposit() {
        accountService.deposit(TEST_ACCOUNT_NO, 50);
        assertEquals(accountService.getBalance(TEST_ACCOUNT_NO), 150, 0);
    }

    @Test
    public void withDraw() {
        accountService.withdraw(TEST_ACCOUNT_NO, 50);
        assertEquals(accountService.getBalance(TEST_ACCOUNT_NO), 50, 0);
    }

    @After
    public void cleanup() {
        accountService.removeAccount(TEST_ACCOUNT_NO);
    }
}

Access the Context with the TestContext Framework in JUnit

If you are using JUnit to create tests with the TestContext framework, you will have two options to access the managed application context. The first option is by implementing the ApplicationContextAware interface or using @Autowired on a field of the ApplicationContext type. For this option, you have to explicitly specify a Spring-specific test runner for running your test SpringRunner. You can specify this in the @RunWith annotation at the class level.

package com.apress.springrecipes.bank;

import com.apress.springrecipes.bank.config.BankConfiguration;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringRunner;

import static org.junit.Assert.assertEquals;

@RunWith(SpringRunner.class)
@ContextConfiguration(classes = BankConfiguration.class)
public class AccountServiceJUnit4ContextTests implements ApplicationContextAware {

    private static final String TEST_ACCOUNT_NO = "1234";
    private ApplicationContext applicationContext;
    private AccountService accountService;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext=applicationContext;
    }

    @Before
    public void init() {
        accountService = applicationContext.getBean(AccountService.class);
        accountService.createAccount(TEST_ACCOUNT_NO);
        accountService.deposit(TEST_ACCOUNT_NO, 100);
    }

    @Test
    public void deposit() {
        accountService.deposit(TEST_ACCOUNT_NO, 50);
        assertEquals(accountService.getBalance(TEST_ACCOUNT_NO), 150, 0);
    }

    @Test
    public void withDraw() {
        accountService.withdraw(TEST_ACCOUNT_NO, 50);
        assertEquals(accountService.getBalance(TEST_ACCOUNT_NO), 50, 0);
    }

    @After
    public void cleanup() {
        accountService.removeAccount(TEST_ACCOUNT_NO);
    }

}

You can specify the configuration classes in the classes attribute of the @ContextConfiguration annotation at the class level. When using XML-based configuration, you can use the locations attribute instead. If you don’t specify any test configuration, the TestContext will try to detect one. It will first try to load a file by joining the test class name with -context.xml as the suffix (i.e., AccountServiceJUnit4Tests-context.xml) from the same package as the test class. Next it will scan the test class for any public static inner classes that are annotated with @Configuration. If a file or classes are detected, those will be used to load the test configuration.

By default, the application context will be cached and reused for each test method, but if you want it to be reloaded after a particular test method, you can annotate the test method with the @DirtiesContext annotation so that the application context will be reloaded for the next test method.

The second option to access the managed application context is by extending the TestContext support class specific to JUnit : AbstractJUnit4SpringContextTests. This class implements the ApplicationContextAware interface, so you can extend it to get access to the managed application context via the protected field applicationContext. However, you first have to delete the private field applicationContext and its setter method. Note that if you extend this support class, you don’t need to specify SpringRunner in the @RunWith annotation because this annotation is inherited from the parent.

package com.apress.springrecipes.bank;
...
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.AbstractJUnit4SpringContextTests;

@ContextConfiguration(classes = BankConfiguration.class)
public class AccountServiceJUnit4ContextTests extends AbstractJUnit4SpringContextTests {

    private static final String TEST_ACCOUNT_NO = "1234";
    private AccountService accountService;

    @Before
    public void init() {
        accountService = applicationContext.getBean(AccountService.class);
        accountService.createAccount(TEST_ACCOUNT_NO);
        accountService.deposit(TEST_ACCOUNT_NO, 100);
    }
    ...
}

Access the Context with the TestContext Framework in TestNG

To access the managed application context with the TestContext framework in TestNG , you can extend the TestContext support class AbstractTestNGSpringContextTests. This class also implements the ApplicationContextAware interface.

package com.apress.springrecipes.bank;

import com.apress.springrecipes.bank.config.BankConfiguration;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.testng.AbstractTestNGSpringContextTests;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;

import static org.testng.Assert.assertEquals;

@ContextConfiguration(classes = BankConfiguration.class)
public class AccountServiceTestNGContextTests extends AbstractTestNGSpringContextTests {

    private static final String TEST_ACCOUNT_NO = "1234";
    private AccountService accountService;

    @BeforeMethod
    public void init() {
        accountService = applicationContext.getBean(AccountService.class);
        accountService.createAccount(TEST_ACCOUNT_NO);
        accountService.deposit(TEST_ACCOUNT_NO, 100);
    }

    @Test
    public void deposit() {
        accountService.deposit(TEST_ACCOUNT_NO, 50);
        assertEquals(accountService.getBalance(TEST_ACCOUNT_NO), 150, 0);
    }

    @Test
    public void withDraw() {
        accountService.withdraw(TEST_ACCOUNT_NO, 50);
        assertEquals(accountService.getBalance(TEST_ACCOUNT_NO), 50, 0);
    }

    @AfterMethod
    public void cleanup() {
        accountService.removeAccount(TEST_ACCOUNT_NO);
    }

}

If you don’t want your TestNG test class to extend a TestContext support class, you can implement the ApplicationContextAware interface just as you did for JUnit . However, you have to integrate with a test context manager by yourself. Please refer to the source code of AbstractTestNGSpringContextTests for details.

Inject Test Fixtures with the TestContext Framework in JUnit

When using the TestContext framework to create tests, you can have their test fixtures injected from the managed application context by annotating a field or setter method with the @Autowired or @Resource annotation. In JUnit, you can specify SpringRunner as your test runner without extending a support class.

package com.apress.springrecipes.bank;
...
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringRunner;

@RunWith(SpringRunner.class)
@ContextConfiguration(classes = BankConfiguration.class)
public class AccountServiceJUnit4ContextTests {

    private static final String TEST_ACCOUNT_NO = "1234";

    @Autowired
    private AccountService accountService;

    @Before
    public void init() {
        accountService.createAccount(TEST_ACCOUNT_NO);
        accountService.deposit(TEST_ACCOUNT_NO, 100);
    }
    ...
}

If you annotate a field or setter method of a test with @Autowired, it will be injected using autowiring by type. You can further specify a candidate bean for autowiring by providing its name in the @Qualifier annotation. However, if you want a field or setter method to be autowired by name, you can annotate it with @Resource.

By extending the TestContext support class AbstractJUnit4SpringContextTests, you can also have test fixtures injected from the managed application context. In this case, you don’t need to specify SpringRunner for your test, as it is inherited from the parent.

package com.apress.springrecipes.bank;
...
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.AbstractJUnit4SpringContextTests;

@ContextConfiguration(classes = BankConfiguration.class)
public class AccountServiceJUnit4ContextTests extends AbstractJUnit4SpringContextTests {

    private static final String TEST_ACCOUNT_NO = "1234";

    @Autowired
    private AccountService accountService;
    ...
}

Inject Test Fixtures with the TestContext Framework in TestNG

In TestNG, you can extend the TestContext support class AbstractTestNGSpringContextTests to have test fixtures injected from the managed application context.

package com.apress.springrecipes.bank;
...
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.testng.AbstractTestNGSpringContextTests;

@ContextConfiguration(classes = BankConfiguration.class)
public class AccountServiceTestNGContextTests extends AbstractTestNGSpringContextTests {

    private static final String TEST_ACCOUNT_NO = "1234";

    @Autowired
    private AccountService accountService;

    @BeforeMethod
    public void init() {
        accountService.createAccount(TEST_ACCOUNT_NO);
        accountService.deposit(TEST_ACCOUNT_NO, 100);
    }
    ...
}                                                                                      

Manage Transactions with the TestContext Framework in JUnit

When using the TestContext framework to create tests , you can have the tests methods run within transactions by annotating @Transactional at the class or method level. In JUnit, you can specify SpringRunner for your test class so that it doesn’t need to extend a support class.

package com.apress.springrecipes.bank;
...
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.transaction.annotation.Transactional;

@RunWith(SpringRunner.class)
@ContextConfiguration(classes = BankConfiguration.class)
@Transactional
public class AccountServiceJUnit4ContextTests {

    private static final String TEST_ACCOUNT_NO = "1234";

    @Autowired
    private AccountService accountService;

    @Before
    public void init() {
        accountService.createAccount(TEST_ACCOUNT_NO);
        accountService.deposit(TEST_ACCOUNT_NO, 100);
    }

    // Don't need cleanup() anymore                
    ...
}

If you annotate a test class with @Transactional, all of its test methods will run within transactions. An alternative is to annotate individual methods with @Transactional, not the entire class.

By default, transactions for test methods will be rolled back at the end. You can alter this behavior by disabling the defaultRollback attribute of @TransactionConfiguration, which should be applied to the class level. Also, you can override this class-level rollback behavior at the method level with the @Rollback annotation, which requires a Boolean value.

Finally, you also need a transaction manager configured in the bean configuration file. By default, a bean whose type is PlatformTransactionManager will be used, but you can specify another one in the transactionManager attribute of the @TransactionConfiguration annotation by giving its name.

@Bean
public DataSourceTransactionManager transactionManager(DataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
}

In JUnit, an alternative to managing transactions for test methods is to extend the transactional TestContext support class AbstractTransactionalJUnit4SpringContextTests, which has @Transactional enabled at the class level so that you don’t need to enable it again. By extending this support class, you don’t need to specify SpringRunner for your test, as it is inherited from the parent.

package com.apress.springrecipes.bank;
...
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.AbstractTransactionalJUnit4SpringContextTests;

@ContextConfiguration(classes = BankConfiguration.class)
public class AccountServiceJUnit4ContextTests extends AbstractTransactionalJUnit4SpringContextTests {
    ...
}

Manage Transactions with the TestContext Framework in TestNG

To create TestNG tests that run within transactions, your test class can extend the TestContext support class AbstractTransactionalTestNGSpringContextTests to have its methods run within transactions.

package com.apress.springrecipes.bank;
...
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.testng.AbstractTransactionalTestNGSpringContextTests;

@ContextConfiguration(classes = BankConfiguration.class)
public class AccountServiceTestNGContextTests extends                
    AbstractTransactionalTestNGSpringContextTests {

    private static final String TEST_ACCOUNT_NO = "1234";

    @Autowired
    private AccountService accountService;

    @BeforeMethod
    public void init() {
        accountService.createAccount(TEST_ACCOUNT_NO);
        accountService.deposit(TEST_ACCOUNT_NO, 100);
    }

    // Don't need cleanup() anymore                
    ...
}                                                                                      

How It Works

In the banking application, you want to integration test your DepositController. Before you can start testing, you need to create a configuration class to configure the web-related beans.

package com.apress.springrecipes.bank.web.config;

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.EnableWebMvc;
import org.springframework.web.servlet.view.InternalResourceViewResolver;

@Configuration
@EnableWebMvc
@ComponentScan(basePackages = "com.apress.springrecipes.bank.web")
public class BankWebConfiguration {

    @Bean
    public ViewResolver viewResolver() {
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        viewResolver.setPrefix("/WEB-INF/views/");
        viewResolver.setSuffix(".jsp");
        return viewResolver;

    }
}

The configuration enables annotation-based controllers by using the @EnableWebMvc annotation; next you want the @Controller annotated beans to be picked up automatically using the @ComponentScan annotation. Finally, there is an InternalResourceViewResolver that turns the name of the view into a URL, which normally would be rendered by the browser, that you will now validate in the controller.

Now that the web-based configuration is in place, you can start to create your integration test. This unit test has to load your BankWebConfiguration class and also has to be annotated with @WebAppConfiguration to inform the TestContext framework you want a WebApplicationContext instead of a regular ApplicationContext.

Integration Test Spring MVC Controllers with JUnit

In JUnit it is the easiest to extend one of the base classes, in this case AbstractTransactionalJUnit4SpringContextTests because you want to insert some test data and to roll back after the tests complete.

package com.apress.springrecipes.bank.web;

import com.apress.springrecipes.bank.config.BankConfiguration;
import com.apress.springrecipes.bank.web.config.BankWebConfiguration;
import org.junit.Before;
import org.junit.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.AbstractTransactionalJUnit4SpringContextTests;
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;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultHandlers.print;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.forwardedUrl;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

@ContextConfiguration(classes= { BankWebConfiguration.class, BankConfiguration.class})
@WebAppConfiguration
public class DepositControllerJUnit4ContextTests extends AbstractTransactionalJUnit4SpringContextTests {

    private static final String ACCOUNT_PARAM = "accountNo";
    private static final String AMOUNT_PARAM = "amount";

    private static final String TEST_ACCOUNT_NO = "1234";
    private static final String TEST_AMOUNT = "50.0";

    @Autowired
    private WebApplicationContext webApplicationContext;

    private MockMvc mockMvc;

    @Before
    public void init() {
        executeSqlScript("classpath:/bank.sql", true);
        jdbcTemplate.update(
            "INSERT INTO ACCOUNT (ACCOUNT_NO, BALANCE) VALUES (?, ?)",
            TEST_ACCOUNT_NO, 100);
        mockMvc = MockMvcBuilders.webAppContextSetup(webApplicationContext).build();

    }

    @Test
    public void deposit() throws Exception {
        mockMvc.perform(
            get("/deposit.do")
                .param(ACCOUNT_PARAM, TEST_ACCOUNT_NO)
                .param(AMOUNT_PARAM, TEST_AMOUNT))
            .andDo(print())
            .andExpect(forwardedUrl("/WEB-INF/views/success.jsp"))
            .andExpect(status().isOk());
    }
  }

In the init method , you prepare the MockMvc object by using the convenient MockMvcBuilders. Using the factory method webAppContextSetup, you can use the already loaded WebApplicationContext to initialize the MockMvc object. The MockMvc object basically mimics the behavior of DispatcherServlet, which you would use in a Spring MVC–based application. It will use the passed-in WebApplicationContext to configure the handler mappings and view resolution strategies and will also apply any interceptors that are configured.

There is also some setup of a test account so that you have something to work with.

In the deposit test method, the initialized MockMvc object is used to simulate an incoming request to the /deposit.do URL with two request parameters, accountNo and amount. The MockMvcRequestBuilders.get factory method results in a RequestBuilder instance that is passed to the MockMvc.perform method.

The perform method returns a ResultActions object that can be used to do assertions and certain actions on the return result. The test method prints the information for the created request and returned response using andDo(print()), which can be useful while debugging your test. Finally, there are two assertions to verify that everything works as expected. The DepositController returns success as the viewname, which should lead to a forward to /WEB-INF/views/success.jsp because of the configuration of the ViewResolver. The return code of the request should be 200 (OK), which can be tested with status().isOk() or status().is(200).

Integration Test Spring MVC Controllers with TestNG

Spring Mock MVC can also be used with TestNG to extend the appropriate base class AbstractTransactionalTestNGSpringContextTests and add the @WebAppConfiguration annotation.

@ContextConfiguration(classes= { BankWebConfiguration.class, BankConfiguration.class})
@WebAppConfiguration
public class DepositControllerTestNGContextTests
    extends AbstractTransactionalTestNGSpringContextTests {

    @BeforeMethod
    public void init() {
        executeSqlScript("classpath:/bank.sql", true);
        jdbcTemplate.update(
            "INSERT INTO ACCOUNT (ACCOUNT_NO, BALANCE) VALUES (?, ?)",
            TEST_ACCOUNT_NO, 100);
        mockMvc = MockMvcBuilders.webAppContextSetup(webApplicationContext).build();
    }

}