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 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")
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")
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.sql based on src/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.)

Developer Documentation