In this post, I will illustrate the integration test infrastructure I used for the jena-nosql project on SpazioCodice’s GitHub account.
The core of the project itself is not associated with specific storage, so a set of integration tests that run towards a (mini)instance of not-well-known target storage is required to ensure the functional correctness of each binding.
Within the project, you can see a (Maven) module dedicated to integration tests: the jena-nosql-integration-tests. It is configured with the Maven Failsafe plugin to run tests, during the integration-test phase, against a running instance of the target storage.
And here comes the beauty because the target storage is not predefined but instead depends on what is the runtime binding module that has been chosen. So basically, the same set of integration tests could be run against Cassandra, HBase, Accumulo, or another storage.
How can we maintain the same set of tests and at the same time start a test instance of one storage or another? Maven profiles is the answer (at least for me): within the pom.xml of the jena-nosql-integration-tests, I defined one profile for each storage (at the time of writing, there’s just one profile 😉 ).
For example, the cassandra-2x profile declares the usage of the Cassandra Maven Plugin that
- starts an embedded instance of Cassandra before all integration tests
- stop that instance after the last integration test
So, in the end, if you want to run the integration test suite against Cassandra, just cd to jena-nosql project directory (where the top-level pom.xml is located) and run Maven as follows:
> mvn clean install -P cassandra-2x
You don’t need to set any permission or any configuration because the embedded instance will “live” within the target build folder.
