Running Unit Tests

From OpenNMS
Jump to: navigation, search

How to Run the Unit Tests

Run them yourself

  1. Checkout the source code
  2. Compile the source code: ./compile.pl
  3. Run the unit tests: ./compile.pl --enable-tests


Unit tests take about 3-4 hours to complete, depending upon hardware. A system with a 2.70GHz i7-3740QM, 16GB ram took about 253 minutes, while the tests running via Bamboo CI took 172 minutes to complete.

Let Bamboo do it instead

If you are doing a lot of long-term development or refactoring that will affect a lot of code, an easier thing to do is to create a branch for your feature or your personal development in git. When you check code into that branch, our Bamboo continuous integration (CI) server will automatically pick up the changes in the branch and rebuild the project, including running the entire unit test suite and smoke test suite.

Considerations when running Unit Tests

You will need a running postgresql database to connect to. The same settings should be used as you would use for a regular opennms install. If you are running the unit tests on a host running other services, or even with an opennms instance, some unit tests might fail due to these services.

Property Default Value Comment
mock.rundbtests true
mock.db.driver org.postgresql.Driver
mock.db.url jdbc:postgresql://localhost:5432/
mock.db.adminUser postgres
mock.db.adminPassword
mock.leaveDatabase false
mock.leaveDatabaseOnFailure false


core/db/src/test/java/org/opennms/core/db/C3P0ConnectionFactoryTest.java

This unit test has a hard-coded dependency upon a local postgresql database with an 'opennms' user with a password of 'opennms', and create database privileges.

Running SonarQube Analysis for Unit Tests Notes

Setup a maven profile for your SonarQube server. Since its likely you will be running the unit tests against a postgresql server, configure your SonarQube server to run via a postgreql database, rather than the embedded h2 database.

<profile>
  <id>sonar-local</id>
  <activation>
    <activeByDefault>false</activeByDefault>
  </activation>
  <properties>
    <sonar.jdbc.url>jdbc:postgresql://localhost/sonar</sonar.jdbc.url>
    <sonar.jdbc.username>sonar</sonar.jdbc.username>
    <sonar.jdbc.password>sonar</sonar.jdbc.password>
    <sonar.host.url>http://localhost:9000</sonar.host.url>
  </properties>
</profile>

You can create a Java Quality Profile called OpenNMS, and use the following checkstyle, findbugs and pmd configuration files: File:SonarQube-OpenNMS.checkstyle.xml.txt, File:SonarQube-OpenNMS.findbugs.xml.txt, File:SonarQube-OpenNMS.pmd.xml.txt.

Alternatively, you can restore the backup File:OpenNMS-SonarQube-backup 2013-08-25.xml.txt which will restore the all the profile settings in one step. Note, this would replace any existing SonarQube configuration settings stored in the database.


Then you can just run compile.pl with the command sonar:sonar to run the unit tests and include the checkstyle, findbugs and pmd results in your sonarqube server. Eclipse also has a SonarQube plugin, which can synchronize with your SonarQube server and display the issues that it found during your most recent unit test run.

./compile --enable-tests -Dmock.test.error.ignore=true \
    -Dmock.test.failure.ignore=true --fail-never -DfailIfNoTests=false \
    -Psonar-local sonar:sonar

As of August 25th 2013, using the above configurations against a build of master resulted in over 180,000 issues inside the OpenNMS project in my SonarQube server. The vast majority of these issues were marked as Major, and were either stylistic issues: extra whitespace at the end of the line, tabs vs spaces, extra whitespaces around certain characters or javadoc issues.