Java/Maven

JUnit Testing Under Maven2

JUnit testing provides an easy to use flexible framework to write unit tests for Java code. Maven incorporates this functionality as part of it’s software life cycle. JUnit plug-in under maven2 is called Surefire.


> mvn test

Putting the above on the command line will compile the test code and run it.This is really convenient when testing someones code or if you are willing to test everything.

Single Test

However if you are the developer and are working on one specific feature tested in one test case you can run:


> mvn -Dtest=MyTestCase test

This will compile all the tests, but will run only the specified one.

Multiple Selected Tests

Sometimes you want to run just a selected set of tests. For example 2 out of 50:


> mvn -Dtest=MyTestCase,MyOtherTestCase test

This will compile all the tests, but will run only the specified two tests.

Wild Cards

You can use ‘*’ in the anywhere in the name of the class. However be careful if you have inner classes as for example My* will match MyTestCase and MyTestCase$1, which is the inner class you have used in the code, but it is not really a test and therefore the build will fail. Link to Documentation .

Cleaning

However what happens if you have discovered a bug or for some other reason edited the functional code (the one you are testing)? You will be surprised, but maven will not pick it up and will continue the old version of the compiled code. To make it compile the entire sub-project you should first clean it.


> mvn clean -Dtest=MyTestCase test

This will clean your target/ directory and therefore get rid of the old compilations. Then it will recompile the whole project along with the testing code, but still run only MyTestCase.

Abstract Tests

Before Maven 2.0.8 test cases starting with a word Abstract were not considered to be real tests. Abstract Tests are usually used if you have some testing code, which is common for 2 test cases. Then you would write an Abstract*Test class and extend it by the 2 test cases. The inheritance allows you to have the code in one place, but Abstract tests are not really test cases, so they should not be run. This changed with the new version. Excludes property contains the patterns of names, which should be excluded from testing. With its help you can remove the Abstract tests again if your project relies on it.In your pom.xml you should add:


  <build>

    <plugins>

      <!-- Added test excludes for Abstract -->
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-surefire-plugin</artifactId>
          <configuration>
            <excludes>
              <exclude>**/Abstract*</exclude>
            </excludes>
          </configuration>
      </plugin>

      <!-- ....... other configuration ....... -->

    </plugins>
  </build>

Standard
Java/Maven

Maven Variables in Java context

Maven is a very convenient and powerful tool for managing large projects, their builds, testing, deployment, versions, etc. It is so great, that sometimes it would be nice to have access to Maven variables from Java or other source language.

For example when writing a test case with JUnit I would like to use some data in an XML file. The file is distributed with the project as part of testing routines.

However getting hold of it’s location in Java is not easy.

  1. One could use the current working directory and assume that it is always the project root (where the pom.xml file is located), but that is really really not flexible although really simple when there is just one project to build.
  2. One could try fiddling with the Class Loader and possibly find the location of a specific class and then from that deduce the location of the test file. Very tedious and somewhat not elegant.
  3. One could try getting hold of one of Mavens variable values. For example ${basedir} contains the project root. This would be flexible and quite general as the code will be run through Maven all the time anyway.

So let’s look at option 3 more closely. Maven variables can be used in the maven scripts. If you are writing Maven plugins there are ways of getting these values. But if you are running a separate application, which is not part of Maven – there is no easy solution.

One way is to use the filtering capabilities of Maven.

For example, one could have a myproject.properties file somewhere in the project, where you would specify some configuration options.


// src/test/resources/myproject.properties
// .............
project.root=${basedir}
// .............

Now we have to let Maven know that it should help us and nicely provide the values we are after.

<!-- pom.xml -->
<project>
  <build>
    <testResources>
       <testResource>
         <directory>src/test/resources</directory>
         <filtering>true</filtering>
       </testResource>
    </testResources>
 </build>
</project>
       

The testResources directive with the filtering turned on will ask Maven to go through all files in src/test/resources and replace the Maven variables within then with the values. After it has done that it will put the files on the classpath of your application so you can get hold of them really easy.If one were to replace testResources with resources it would affect the application execution rather than just the testing.In Java all you have to do is load the properties file and there you go:


java.util.Properties props = new java.util.Properties();

// Get hold of the path to the properties file
// (Maven will make sure it's on the class path)
java.net.URL url = Config.class.getClassLoader().getResource("sql.properties");

// Load the file
props.load(url.openStream());

// Accessing values
porps.getProperty( "project.root" ); // This will return the value of the ${basedir}

That is it, we are done. Now that we have the project root, it is trivial to reference any file within the source tree with no dependence on the class layout or the current directory.

Standard