Question

I have a project which I am building with Maven which uses Hibernate (and Spring) to retrieve data from a database, etc.

My “tests” for the DAOs in my project extend Spring’s AbstractTransactionalDataSourceSpringContextTests so that a DataSource can be wired into my class under test to be able to actually run the query/Hibernate logic, to fetch data, etc.

On several other projects I’ve used these types of test in concert with a HSQL database (either in-memory or pointed at a file) to be able to efficiently test the actual database querying logic without relying on an external database. This works great, since it avoids any external dependencies and the “state” of the database prior to running the tests (each of which are wrapped in a transaction which is rolled back) is well defined.

I’m curious though about the best way to organize these tests, which are really a loose flavor of integration tests, with Maven. It feels a bit dirty to keep these tests in src/test/java, but from what I’ve read there doesn’t seem to be a consistent strategy or practice for organizing integration tests with Maven.

From what I’ve read so far, seems like I can use the Failsafe plugin (or a second instance of Surefire) and bind it to the integration-test phase, and that I can also bind custom start-up or shutdown logic (such as for starting/stopping the HSQL instance) to pre-integration-test or post-integration-test. But, is this really the best method?

So my question basically is – what is the generally accepted best practice on organizing this with Maven? I’m having trouble finding any sort of consistent answer in the documentation.

What I’d like is to:

• Seperate unit tests from integration tests, so only unit tests are run during the test phase
• The ability to bind custom startup/shutdown logic to pre-integration-test and post-integration-test
• Have the reports from the integration-tests merged/presented with the unit test Surefire reports

Answer 1

There is this codehaus page with some guidelines. I found the failsafe plugin a bit of a hack, and it makes running the unit tests in Eclipse fiendishly complicated. I do broadly what you’re describing.

Define integration tests in src/itest/java
In the pre-integration-test phase:

• Clear target/test-classes
• Use the build-helper-maven-plugin‘s add-test-source goal to add the itest source location
• Use a custom Mojo to remove src/test/java from the configuration so the unit tests are not compiled again (I don’t really like this, but it’s needed to maintain the separation of unit and integration tests).
• Use the compiler-plugin to compile the integration tests

Then in the integration-test phase, use the surefire-plugin to run the tests.

Finally, bind any tidy up goals to the post-integration-test phase (though normally they’re not needed as you can use the test teardown() to tidy up).

I’ve not yet found a way to merge the test results as the reporting phase has passed, but I
tend to view the integration tests as an added bonus, so as long as they pass the report is not so important.

Update: I think it’s worth pointing out that you can run Jetty from within your integration tests rather than using a jetty goal. This gives you much finer control over the tests. You can get more details from this answer and the referenced blogs.