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 Type | Code to Run Test | Description | Naming Convention | Can 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
- In your JUnit run configuration, add the following system properties (e.g -Duser.pass="foobar")
tdar.baseurl (e.g. -Dtdar.baseurl="http://alpha.tdar.org:80")
- tdar.user (e.g. -Dtdar.user="test@tdar.org")
- tdar.pass(e.g. -Dtdar.pass="test")
- 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:
- drop your tdarmetadata database
- run src/main/db/load_tdarmetadata_database.sh to reinitialize your database with the appropriate test data
- run
mvn -PsqlExtract initialize compile exec:java - this should rebuild
src/test/db/init-test.sqlbased onsrc/test/db/extractRecords.sql - 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.)