Unit and Integration Testing

Running Tests in tDAR

We use a number of maven tools/plugins to run and manage tests in tDAR.  These include, surefire, failsafe, and a custom profile. Currently we have 3 types of tests in tDAR (unit tests, integration tests, and web tests).

Running tests:

Test TypeCode to Run TestDescriptionNaming ConventionCan be run in Eclipse JUnit Tester
Unit Tests
mvn -Ptest clean test

These run simple unit tests that test basic logic and functionality in the code without the need for Spring, Hibernate or a web environment. Examples are parts of the filestore, string cleaning, etc.

All test class names should end with Test.Yes
Integration Tests
mvn -Ptest clean verify
These are more complex tests of the tDAR application logic and use a test database, spring, struts2, hibernate. These test full application logic and controller issues as well as database interaction. These tests are susceptible to being run inside of Eclipse's Junit test runner but require the test database to be setup ahead of time. Tests can be targeted by using the property: it.test=MyTestClassSimpleName. All test class names should end with ITCase.Yes
Web Tests (part of integration tests)
mvn -Ptest clean verify
These are a subset of the integration tests that look at testing tDAR from the outside in (that is they interact with tDAR as a web browser only and attempt to test the freemarker and user interaction components of tDAR. These tests need to be run as a maven task specifically. Tests can be targeted by using the property: it.test=MyTestClassSimpleName.All test class names should end with WebITCase.No


The maven test profile:

The maven test profile is used to configure maven to use /src/test/resources to look for additional properties and make sure that it runs properly. It runs in a clean crowd instance and ensures that jetty runs on a different port.

Running WebITCase tests against an alternate tDAR instance using JUnit

One of the drawbacks to running the web tests using verify goal is that you don't have visibility to the local jetty instance's log messages.  You can get around this by running the web tests in JUnit, however, you'll first need to instruct the webtests to connect to a different server (since the test jetty instance will not be created).  There are a couple ways to go about this...

Option 1 - Running the web tests against to a stand-alone instance of tDAR

  1. In your JUnit run configuration, add the following system properties (e.g -Duser.pass="foobar")
    1. tdar.baseurl (e.g. -Dtdar.baseurl="http://alpha.tdar.org:80")

    2. tdar.user (e.g. -Dtdar.user="test@tdar.org")
    3. tdar.pass(e.g. -Dtdar.pass="test")
  2. Run the test using JUnit instead of via the maven verify goal

Option 2 - Running the web tests against a stand-alone test jetty instance

Similar to above, instead of modifying the test constants you modify the web app config to run a standalone instance of the test version of your web app. 

  • Modify /src/main/resources/hibernate.properties to specify the test database (i.e copy/paste the values from src/test/resources/hibernate.properties)
  • Modify /src/main/resources/crowd.properties to specify the test authentication host
  • In the JUnit run configuration, add the following system property:
    • -Dtdar.baseurl="http://localhost:8080"

Writing Tests in tDAR

Starting Points

Rebuilding the test database (updating src/test/db/init-db.sql):

By default, running the full integration test will reset and rebuild the test database.  However, just after a release, or after a major schema change is made (often when data is removed or moved) it may be necessary to rebuild the script that populates the test database. This can be done with the following process:

  1. drop your tdarmetadata database
  2. run src/main/db/load_tdarmetadata_database.sh to reinitialize your database with the appropriate test data
  3. run mvn -PsqlExtract initialize compile exec:java
  4. this should rebuild src/test/db/init-test.sql based on src/test/db/extractRecords.sql
  5. refresh the mercurial tree and then commit changes

extractRecords.sql should only need to be modified when there are significant changes to the schema (e.g., consolidating tables or other table-level changes, or adding new test data, new resource ids, etc.)


Integration Testing

Tests involving database transactions

Testing the web application layer

Unit Testing