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 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(); } } }
Using AcrossTestContextConfiguration will always reset the database represented by the datasource before booting up the AcrossContext. Note that due to limitations of the Liquibase "dropAll" script, at time of writing this only drops tables and keys, not stored procedures etc.
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 is used.
The across-test package currently comes with the jdbc drivers for MySQL, Oracle and SQL Server. For other databases you will still have to provide the driver dependencies yourself.
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:
Datasource | DBMS |
---|---|
mysql | MySQL 5 (linux) |
oracle | Oracle 11G (Windows) |
mssql | SQL Server 2008 |