Integration tests

JUnit and Integration tests

Integration tests are run using the maven failsafe plugin. For detailed information see the Maven failsafe documentation.

Short version:

• any JUnit class Test* or *Test will be run by the test target
• any JUnit class IT* or *IT will be run by the verify target (run after the test target)

Usually the following are unit tests:

• any test that mocks almost all dependencies
• any test that does not depend on any database (hsqldb included)

The following should be considered integration tests:

• any test that boots an AcrossContext that contains the module under test or the modules it depends on

POM configuration

The failsafe plugin needs to be configured in the pom.xml.  For simplicity sake (buildserver and Sonar integration), the failsafe reports are put in the same folder as the surefire (unit tests) reports.

<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-failsafe-plugin</artifactId>
			<version>2.17</version>
			<configuration>
				<reportsDirectory>${project.build.directory}/surefire-reports</reportsDirectory>
			</configuration>
			<executions>
				<execution>
					<goals>
						<goal>integration-test</goal>
						<goal>verify</goal>
					</goals>
				</execution>
			</executions>
			<dependencies>
				<dependency>
					<groupId>org.apache.maven.surefire</groupId>
					<artifactId>surefire-junit47</artifactId>
					<version>2.17</version>
				</dependency>
			</dependencies>
		</plugin>
	</plugins>
</build>

Running only the integration tests

When you execute mvn verify then first the unit tests will be executed, followed by the integration tests.  You can run only the integration tests by running mvn failsafe:integration-test.  If you start from a clean checkout, you need to compile them as well: use mvn compile test-compile failsafe:integration-test.

Supporting multiple databases

If a module extends the database schema, it should preferably have one or more integration tests that perform the module installation and can easily be re-run against different datasources.

Using across-test

There is a package across-test that contains a set of base classes to create test AcrossContext, with some facilities to externalize the datasource that should be created.

<dependency>
	<groupId>across</groupId>
	<artifactId>across-test</artifactId>
	<scope>test</scope>
</dependency>

In your unit tests you do not have to take care of creating a datasource yourself.  By importing the AcrossTestContextConfiguration a blank AcrossContext with a valid DataSource will be created.  You can provide one or more AcrossTestContextConfigurer instances to add modules to the context, or modify the context settings.

@RunWith(SpringJUnit4ClassRunner.class)
@DirtiesContext
@ContextConfiguration(classes = ITUserModule.Config.class)
public class ITUserModule
{
	@Autowired
	private UserService userService;	// This is an exposed service from the UserModule
	
	...

	@Configuration
	@Import(AcrossTestContextConfiguration.class)
	static class Config implements AcrossTestContextConfigurer
	{
		@Override
		public void configure( AcrossContext context ) {
			context.addModule( acrossHibernateModule() );
			context.addModule( userModule() );
		}

		private AcrossHibernateModule acrossHibernateModule() {
			return new AcrossHibernateModule();
		}

		private UserModule userModule() {
			return new UserModule();
		}
	}
} 

Across test datasource

AcrossTestContextConfiguration creates a datasource based on a properties file.  The properties file should be located in ${user.home}/dev-configs/across-test.properties and can contain multiple datasource definitions.  By providing another property acrossTest.datasource, you can specify which datasource from the properties file should be used.  If no acrossTest.datasource property is found, the default is auto which will result in an in-memory HSQLDB being used.

You can specify acrossTest.datasource as a system property to easily define the datasource at runtime.  If you want to always run a particular datasource locally, you can also put a value for acrossTest.datasource.default directly in the across-test.properties file.

# If you uncomment this your local unit tests will use the oracle datasource
#acrossTest.datasource.default=oracle

acrossTest.datasource.mysql.driver=com.mysql.jdbc.Driver
acrossTest.datasource.mysql.url=jdbc:mysql://localhost:3306/across_test
acrossTest.datasource.mysql.username=across_test
acrossTest.datasource.mysql.password=across_test
 
acrossTest.datasource.oracle.driver=oracle.jdbc.OracleDriver
acrossTest.datasource.oracle.url=jdbc:oracle:thin:@127.0.0.1:1521:fe
acrossTest.datasource.oracle.username=across_test
acrossTest.datasource.oracle.password=across_test

Buildserver datasources

The buildserver is provided with a default across-test.properties containing the following datasources: