Run a specific test

The problem:

You have a group of unit tests that you run through the Maven Surefire plugin. You do not want Surefire to run all the tests, rather you want only one specific test to run.

The solution:

This one is easy, all you need to do is put a little something into your command to tell the Surefire plugin "run just this one test". What does this look like? Here is an example: "mvn -Dtest=FunTest package". Here you want to package your applicaiton, but you are going to run the FunTest first. Notice you don't put a ".java" or ".class" extension onto the name. Thats it, you can use the "-Dtest=..." to run a single test anytime that the Surefire plugin will be run.

Do Not Test!!!

The problem:

You would like to skip unit testing when using Maven.

The solution:

You can very easily tell Surefire, the plugin in Maven that handles testing, to not run tests. All you need to do is specify the system property 'maven.test.skip. Here is an example:

mvn -Dmaven.test.skip clean package

The above command will clean and package your project and will do so without running your tests. This is a very useful command in Maven. It comes in especially handy when trying to build someone else's project that contains non-portable test that run by default. These may keep you from building their project. Use this command to build the project and maybe install or deploy it.

Integration Testing in your Maven Application

The problem:

You want to create integration tests in your Maven project. You don't want these tests to run every time you compile.

The solution:

Create some profiles in your pom.xml. You can create a profile that by default excludes running any test that starts or ends with the words 'IntegrationTest'. You can then include a profile that will run these tests when activated.

Here is an example you can use in your pom:

 
<!-- Use this profile to allow integration tests to run -->
<profiles>
    <profile>
        <id>no_integration_testing</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
        <build> 
            <plugins>   
                <plugin>        
                    <artifactId>maven-surefire-plugin</artifactId>
                    <configuration>     
                        <excludes>              
                            <exclude>**/*IntegrationTest.java</exclude>
                            <exclude>**/IntegrationTest*.java</exclude>                         
                        </excludes>             
                    </configuration>    
                </plugin>       
            </plugins>  
        </build>
    </profile>  
    <profile>
        <id>integration_testing</id>
        <build> 
            <plugins>   
                <plugin>        
                    <artifactId>maven-surefire-plugin</artifactId>
                    <configuration>     
                        <includes>              
                            <include>**/*IntegrationTest.java</include>
                            <include>**/IntegrationTest*.java</include>
                        </includes>             
                        <excludes>              
                        </excludes>             
                    </configuration>    
                </plugin>       
            </plugins>  
        </build>
    </profile>
</profiles>

If you use this configuration, by default a test called "LegacySystemIntegrationTest" would not get run by surefire when you compile. If you issue the command

"mvn -P integration_testing compile"

then this integration test (and any others named in this fashion) will get run. Note there are some gotchas when using this strategy:

1. If you include the profiles above in a pom that gets inherited, the pom which inherits may override the default excludes. If the sub-pom does override excludes the entries from the profile go away and tests with "IntegrationTest" in them will get run by Surefire.
2. Any integration tests that do not start or end with "IntegrationTest" will get run. You are expected to follow a convention here. You could add more excludes and incluedes to my example above in this case though.

My advice is that you use this configuration, and by convention always name integration tests with "IntegrationTest" in them. It saves headaches and normalizes development across all users.

Maven 2 + Hibernate + HSQLDB (project contained integration testing for Hibernate)

The problem:

You must check your Hibernate objects against a database for testing purposes. This database is somewhere on your network, and accessible to many of your fellow co-workers. You cannot expect anything to stay static in this db, which means eventually your tests will fail.

A solution:

Maven can make projects very portable. Hibernate makes working with persistent objects simple. HSQLDB is a Java database that you can run embeded in other programs.

A problem with using Hibernate is it can take away some of the portability of your project. This happens because you must provide a database for making your objects persistent. In doing so your test configuration files will be spec'd to a single database. What happens when someone runs the project's tests and does not have access to the test database? The tests will fail :( We want to have unit tests be used for all our hibernate objects. It is especially important to thoroughly test them, as they will be a central part of your projects functioning properly (especially web projects!).

Luckily Maven makes it easy to use one database for testing, and another for production. This is where HSQLDB can come in handy. You can create a hibernate config just for testing which connects to an in memory HSQL database. You will need the proper files in src/test/resources folder of your Maven 2 project. The files include the test version of your hibernate config file. I put the hibernate mapping files into folders that mirror the packaging of the POJO object classes. When you run 'mvn package' the .hbm files will be placed in the same folder as the POJO class they belong to. Here is an example of my Maven 2 project's structure:

/project
pom.xml
...other files
/src
/main
    /java
        /some
            /package
                Foo.java
    /resources
        hibernate.cfg.xml
        /some
            /package
                Foo.hbm.xml
/test
    /java
        /some
            /testpackage
                TestFoo.java
    /resources
        hibernate.cfg.xm

So you can see that there are a hibernate configuration file for the build and the test phase. Now in the test hibernate.cfg.xml file you will need to have the following properties set:


<!-- Database connection settings -->
<!-- HSQL DB -->
<property name="connection.driver_class">org.hsqldb.jdbcDriver</property>
<property name="connection.url">jdbc:hsqldb:mem:aname</property>
<property name="connection.username">sa</property>
<property name="connection.password"></property>

and...

<property name="dialect">org.hibernate.dialect.HSQLDialect</property>
<mapping resource="some/package/Foo.hbm.xml" />


These entries should have you now set up to use a in memory database for all your testing with hibernate. But before this will work you need to do one more thing.

Set up you Maven 2 project so that HSQLDB is a dependency. Added this dependency section to your project:

<dependency>
  <groupId>hsqldb</groupId>
  <artifactId>hsqldb</artifactId>
  <version>1.8.0.1</version>
</dependency>

Note that you will not need to make any specific JDBC driver available. The HSQLDB dependency contains the proper driver!

Using this recipe you will be able to make very portable Maven/Hibernate projects. Users any place in the world will be able to check out your project and test it immediately. If they would like to test using their own database it is not hard for them to overwrite what is in the src/test/hibernate.cfg.xml file.